Diff算法不参与拖拽过程，仅在排序后通过响应式更新触发，依托稳定key和虚拟滚动实现精准增量DOM更新。
Diff 算法本身不直接用于拖拽交互，但它在拖拽引发的视图更新阶段起关键作用——尤其当配合虚拟滚动与响应式数据结构时，能避免全量重渲染，实现“只更新变化的行”。真正的高性能拖拽，是拖拽逻辑 + 虚拟滚动 + 增量 DOM 更新三者协同的结果，而 Diff 是其中保障视图精准、轻量同步的核心一环。
拖拽过程不触发 Diff，但排序后必须依赖它
浏览器原生拖拽（或 SortableJS / Vue.Draggable）只负责捕获位置变化、交换数组索引。此时 Vue 或 React 并不会自动感知“哪几行移动了”，除非你显式更新响应式数据。一旦执行类似 this.list.splice(oldIndex, 1); this.list.splice(newIndex, 0, item) 这样的操作，响应式系统就会触发更新，进而进入虚拟 DOM 的 diff 阶段。
关键在于：Diff 的效率，取决于你提供给渲染器的 key 是否稳定、是否反映真实顺序。常见错误是用数组索引 :key="index" —— 拖拽后索引全乱，Diff 认为所有节点都变了，导致大量无谓的 DOM 移动和重绘。
正确做法：
- 每行数据必须有唯一、稳定、业务语义化的 id 字段（如
row.id），并用作:key - 拖拽仅改变数组顺序，不修改任何 row.id，确保 Diff 能准确识别“同一行只是换了个位置”
- Vue 会基于 key 复用节点，只调整其在父容器中的物理位置（
moveNode），跳过属性比对与重建
虚拟节点重排：让 Diff 只处理“可见部分”
即使 Diff 很快，若一次性比对上万行的 vnode，开销依然巨大。虚拟滚动（如 RecycleScroller）通过限制渲染范围，把 Diff 的输入规模从 N 行压缩到约 20–50 行（可视区 + 缓冲区）。
此时，Diff 实际运行在精简后的 filteredList 上，而非原始大数据集。哪怕用户拖动的是第 1 条到第 9999 位，Diff 也只看到当前窗口内的那几十个 vnode，并快速定位出“哪个 vnode 应该出现在哪个 slot”。
实现要点：
- 将
<draggable>包裹在<RecycleScroller>内部，而非相反（否则虚拟滚动失效） -
filteredList必须是计算属性或响应式代理，随滚动实时 slice 出当前页数据 - 确保
item-size精确（像素值固定）或使用item-height动态估算，否则滚动条高度不准，影响拖拽反馈
结合 patchFlags 与静态提升进一步提速（Vue 3 特有）
Vue 3 的编译器会在模板中注入 patchFlag，标记哪些 vnode 属性是动态的（如 {{ row.name }}）、哪些是静态的（如列头文字）。拖拽排序后，若行内只有顺序变化、内容未变，Vue 就能跳过文本节点的比对，直接复用。
实操建议：
- 表格单元格尽量写成纯插值
{{ row.name }}，避免v-if、v-for嵌套在行内部 - 表头、操作列等不变内容，用
v-once或提取为独立组件 +defineComponent({ name: 'TableHeader' })，触发静态提升 - 禁用不必要的响应式：对只读展示字段（如 ID、创建时间），可考虑用
Object.freeze()或shallowRef降低 proxy 开销
绕过 Diff：用原生 DOM 移动做最后优化
当性能要求极致（如万级实时拖拽+动画），可局部“降级”：在 onEnd 回调中，不依赖 Vue 更新数组，而是直接操作真实 DOM 节点位置。
例如用 SortableJS 的 onMove + onEnd，结合 document.elementFromPoint 定位目标行，调用 targetRow.parentNode.insertBefore(draggedRow, targetRow)。这种方式完全跳过虚拟 DOM 和 Diff，帧率更稳。
注意前提：
- 必须关闭 Vue 的过渡动画（
<transition-group>会干扰 DOM 直接操作） - 后续仍需同步更新
this.list数组，保证数据与视图最终一致（可在 nextTick 后赋值） - 仅推荐用于核心交互区域，其他非拖拽逻辑（如搜索、分页）仍走标准响应式流程
