多列表拖拽撤销功能需在drop时保存源目标快照并生成逆向操作，撤销时直接恢复快照或执行反向更新；须记录列表ID、路径、索引等元数据，采用快照保底+差分优化策略，并用栈管理带长度限制与合并机制。
多列表拖拽的撤销功能，核心在于记录每次拖拽操作的“快照”和“逆向操作”，而不是简单地刷新或回退状态。关键点是：在拖拽完成（drop）时立刻保存变更前的完整数据快照，并生成可执行的还原动作；撤销时不是靠历史堆栈倒放事件，而是直接恢复快照或执行反向更新。
1. 拖拽前记录源与目标的原始状态
在 dragstart 或更稳妥的 dragend（配合防抖）之前，先捕获当前所有列表的数据结构。推荐用不可变方式深拷贝（如 JSON.parse(JSON.stringify(data)) 或 structuredClone），避免引用污染。
- 每个列表用唯一 ID 标识（如
listA,listB） - 每条拖拽记录包含：
fromListId、toListId、itemIds（被拖项 ID 数组）、fromIndex、toIndex - 同时保存拖拽前各列表的完整数组（含顺序），这是还原的基准
2. 撤销动作 = 恢复快照 + 反向移动
撤销不等于“把 item 再拖回去”，而是按记录的原始快照重置整个状态，或精确计算反向操作：
- 若使用快照模式：直接将整个数据状态替换为上一步保存的快照对象
- 若用差分模式：根据原
fromListId和toListId，把 item 从目标列表删掉，再插回源列表原位置（注意 index 偏移：如果目标列表在拖入后发生了增删，需用原始fromIndex和toIndex推算） - 推荐混合策略：快照用于保底（防止逻辑错乱），差分用于性能（避免频繁深拷贝大数组）
3. 多列表间嵌套/跨级拖拽要额外记录层级路径
当列表支持嵌套（如看板中“进行中”下还有“高优”、“低优”子列），光记 listId 不够，需记录完整路径，例如 ["board-1", "column-in-progress", "priority-high"]。
- 拖拽开始时，通过 DOM 向上遍历或数据映射，获取被拖项当前的完整路径
- 撤销时，按路径定位到源节点，执行插入；若路径已不存在（如该子列被删除），则降级还原到父级或触发告警
- 路径也应纳入快照，确保还原环境一致
4. 撤销栈管理与边界控制
用一个数组栈（undoStack）存操作记录，每次成功 drop 就 push 一条；撤销就 pop 并执行还原，再把该操作推入 redoStack（用于重做）。
- 限制栈长度（如最多 50 步），避免内存泄漏：每次 push 前检查长度，超限则 shift 掉最老记录
- 用户连续快速拖拽时，可合并为单步（如 300ms 内多次 drop 归为一次记录），避免粒度过细
- 任何非拖拽引起的状态变更（如手动编辑 item 内容）也应触发新快照，保证撤销链不断裂
