本文详解如何在 svelte 中结合 sortablejs 实现多个动态嵌套列表的稳定拖拽排序，重点解决因缺失 key、状态同步不一致导致的 ui 错乱、重复移动等问题，并提供基于 action 的简洁、可维护方案。
在 Svelte 中集成 SortableJS 处理多组动态列表（如分类看板）时，常见问题并非来自 SortableJS 本身，而是 Svelte 的响应式更新机制与 DOM 同步逻辑未对齐所致。最典型的症状包括：列表项“双倍移动”、拖拽后顺序回滚、跨列表拖入失败或 UI 滞后——这些几乎都指向两个核心缺陷：#each 缺失唯一 key 和 组件状态与顶层数据源双向绑定失控。
✅ 正确做法一：强制 #each 使用稳定 key
Svelte 的 #each 块默认使用数组索引作为隐式 key。当列表顺序变化（尤其跨列表拖拽）时，索引快速重排会导致 DOM 元素被错误复用或销毁，引发视觉抖动与状态错位。必须显式指定唯一、稳定、不可变的 key：
{#each category as item (item.id)}
(item.id) 是关键——它告诉 Svelte：“此
✅ 正确做法二：用 use: action 替代自定义组件封装
将 Sortable 初始化逻辑封装进独立组件（如 List.svelte）看似模块化，实则引入了额外的状态层（arr = fullArr[index]）、生命周期耦合（onMount 时机）及响应式陷阱（直接赋值 fullArr[index] = ... 可能绕过 Svelte 的响应式追踪）。更优解是使用 Svelte Action —— 它天然绑定到 DOM 元素，生命周期清晰，且与顶层状态完全解耦：
{#each items as category, i}
Category {i}
-
{#each category as item (item.id)}
- {item.name} {/each}
{JSON.stringify(items, null, 2)}? 为什么 items = [...items] 不可省略？items[fromIdx].splice(...) 和 items[toIdx].splice(...) 直接修改了嵌套数组的内部结构，但 Svelte 不会自动检测深层嵌套变更。重新赋值 items = [...items] 触发顶层引用变更，强制 Svelte 重新 diff 整个 items 结构，确保 UI 精确同步。
✅ 进阶建议：使用 onSort 还是 onEnd？
- onSort: 适合仅需单列表内排序，通过 sortable.toArray() 获取 ID 序列再映射回对象。但跨列表时需遍历 items.flat() 查找，性能略低且易受重复 ID 影响。
- onEnd: 推荐用于多列表场景。event.from/event.to 明确指示来源与目标容器，event.oldIndex/event.newIndex 提供精确位置，配合 .splice() 可实现原子级、零副作用的数据迁移，逻辑更清晰、性能更优。
? 总结：三大避坑原则
- 永远为 #each 显式声明 (key) —— 尤其涉及拖拽、增删、排序等 DOM 重排操作；
- 优先选用 use: action 而非自定义组件封装第三方库 —— 减少状态桥接、避免生命周期冲突；
- 深层嵌套数组变更后，必须触发顶层响应式更新 —— arr = [...arr] 或 arr = structuredClone(arr) 是安全写法。
遵循以上实践，即可构建出响应灵敏、行为确定、易于维护的 Svelte + SortableJS 多列表拖拽系统。
