摘要
昨天我讨论了一个拖拽问题：如果把一篇文章从某一天拖到另一天，系统要不要连同它的日期归属一起改？
我的答案是要改，而且应该由后端维护一致性。因为日期不只是前端上的标签，它会影响文章位置、排期、预览、发布和后续查找。
这篇文章讲的是为什么拖拽交互背后必须有清楚的数据语义。
目录
- 拖动文章不是只改 UI
- 日期为什么是数据事实
- 文章拖拽和任务拖拽有什么区别
- 为什么一致性要放后端
- 长期收益
- FAQ
拖动文章不是只改 UI
在内容日历里，用户把一篇文章从今天拖到明天，看起来只是一次界面操作。
但从系统角度看，这个动作表达了一个意图：这篇文章现在属于新的日期。
如果前端只把卡片挪过去，后端仍然认为它属于旧日期，问题就会出现。预览可能指向旧位置，发布可能读取旧文件，排期可能和文章日期不一致。
这种“看起来移动了，实际没移动”的状态最危险。
日期为什么是数据事实
在内容系统里，日期通常不只是展示字段。
它可能出现在目录命名、文章元数据、排期任务、发布历史和每日列表里。
如果日期变了，相关引用也要一起更新。否则同一篇文章会在不同地方呈现不同事实。
所以我把日期看作数据事实，而不是前端样式。
文章拖拽和任务拖拽有什么区别
这里有一个关键区分。
拖动文章，表达的是文章本身改日期。比如原本属于某一天的文章，现在归到另一天。
拖动排期任务，表达的是执行时间变化。它不一定意味着文章源内容的日期也要改。
如果不区分这两种动作，系统就会把“我想明天发”误解成“这篇文章属于明天”。
所以拖拽动作必须有语义边界。
为什么一致性要放后端
前端可以负责交互，但一致性规则应该放后端。
因为后端更接近数据事实。它知道哪些字段要一起改，哪些引用要同步更新，哪些情况不能动。
如果把这些逻辑散在前端，未来多一个入口，比如批量移动、自动排期、账号视角，就可能出现不同入口改法不一致的问题。
后端统一处理，系统才稳。
长期收益
长期收益是减少隐性错乱。
用户可以放心拖拽，不用担心后台还是旧状态。开发者也可以放心增加新入口，因为一致性规则已经集中在后端。
内容系统越复杂，这种一致性越重要。否则每个小交互都会成为未来排查的坑。
FAQ
拖动文章一定要改目录或归属吗？
如果目录或归属日期就是文章事实的一部分，就应该改。
拖动排期任务也要改文章日期吗？
不一定。排期任务改变的是发布计划，不一定改变文章源内容。
为什么不只在前端处理？
前端只能改显示。后端必须维护真正的数据一致性。