演示里加入拖放很容易，让它可靠地服务真实工作则更难。
产品要回答的不是“元素能否移动”，而是用户能否安全调整顺序、理解变化、保存结果，并在出错时恢复。
1. 用户调整步骤顺序
2. 界面显示未保存修改
3. 用户保存新顺序
4. 服务器校验顺序
5. 页面显示已保存结果这与只修改客户端状态不同。顺序通常影响后续工作流，保存失败时，应用不应假装结果已持久化。
Pragmatic Drag and Drop 等库负责困难的交互模式，同时让产品保留数据模型的决定权。拖放应产生清楚的排序意图，而不是决定业务规则。
type ReorderInput = {
itemId: string;
beforeItemId?: string;
afterItemId?: string;
};具体结构可以变化，重点是界面发送明确操作，而不是含糊的客户端状态包。
真实排序任务不能只有拖放一条路。用户需要能通过无需鼠标、容易理解和访问的控件将项目上移或下移。
保存方式也很重要。即时保存看起来快，但用户想连续移动多次、检查最终顺序时，批量保存更从容。界面应明确展示已修改但未保存的状态。
服务器仍需拒绝缺失项目、重复位置和无权执行的修改。客户端能帮助避免错误，却不能是唯一防线。
排序界面有比初看更多的状态：空闲、拖动、已修改未保存、保存中、已保存和失败。不设计这些状态，用户就会困惑：改变的是屏幕上的顺序，还是产品中的顺序？
排序频繁且视觉位置有助于任务时，我会使用拖放；普通优先级数字、选择菜单或上下移动按钮更清晰时，就不用。
目的不是让界面显得活泼，而是让用户表达真实的排序决定，并可靠地保存下来。