嵌套列表拖拽卡顿主因是dragover频繁触发重排重绘，尤其5层以上时getboundingclientrect()和closest()开销剧增；优化关键为用transform替代dom位移、配合will-change: transform，并将dragover/drop事件代理至根容器统一处理。
为什么嵌套列表拖拽会卡顿
不是 DOM 太多，而是每次 dragover 都触发重排 + 重绘，尤其在多层 <div> 嵌套下，浏览器要反复计算每一层的盒模型、样式继承和布局边界。5 层以上嵌套时，<code>getBoundingClientRect() 调用本身就会明显延迟，更别说配合 insertBefore() 移动节点——它会强制同步更新整个子树。
- 嵌套层级越深，
closest()向上查找路径越长，事件响应变慢 - 每个子容器若都监听
dragover，事件冒泡叠加导致判断错乱、光标闪烁 - 原生
dataTransfer无法跨 iframe 或 Shadow DOM 传递，嵌套组件间数据同步只能靠全局状态或自定义事件，额外增加开销
减少重排的关键：用 CSS transform 替代 DOM 位移
别在 dragstart 里直接改 style.left/top，也别用 margin 模拟拖拽位移——这些都会触发 layout。真正丝滑的做法是只操作 transform: translateY()，并配合 will-change: transform 提前告知浏览器优化。
- 拖拽开始时给被拖元素加
class="is-dragging"，CSS 定义：`.is-dragging { transform: translateY(-50%); will-change: transform; pointer-events: none; }` - 插入逻辑仍用
insertBefore()，但视觉位移全程由 transform 控制，DOM 结构保持静态直到drop - 避免在
dragover中调用offsetTop、clientHeight等触发 layout 的属性，全换成getBoundingClientRect()（它缓存友好）
嵌套容器事件代理必须收口到最外层
不要给每个子 <ul></ul> 或 <ol></ol> 单独绑 dragover/drop，否则事件监听器爆炸式增长，且父容器会拦截子容器的 drop，导致“拖进子列表却插到父列表末尾”。
- 只在根容器（如
#nested-sortable）上监听dragover和drop - 在
dragover回调里用e.target.closest('[draggable]')定位当前悬停项，再用e.target.closest('[data-sortable-container]')找到归属的嵌套容器 - 计算插入点时，以目标容器的
getBoundingClientRect()为基准，而非整个页面坐标——否则滚动后位置偏移 - drop 时先判断目标是否允许接收该类型元素（比如检查
data-type属性），再执行insertBefore()，避免非法嵌套
SortableJS 嵌套配置踩坑点
用 Sortable.create() 套嵌套结构时，默认配置根本扛不住真实业务场景。不是库不行，是默认开关没关对。
-
swapThreshold: 10必设——原生 30 在小卡片或折叠面板里根本拖不动 -
ghostClass: "sortable-ghost"和对应 CSS 必须写死，否则拖拽时看不到占位符，用户不知道要插哪 - 禁用动画：
animation: 0，Chrome 下animation: 150会导致快速拖拽丢帧 - 嵌套子列表需显式传
group: { name: "nested", pull: true, put: true }，否则子列表之间无法互换 - 动态增删嵌套节点后，调用
sortable.destroy()再create()重建，别试图复用旧实例——内部缓存会错乱
offsetTop），都会让 60fps 直接掉到 20fps；而真正的优化，往往藏在 CSS 的 will-change 和事件代理的收口方式里。
