节流在鼠标拖拽中用于协调视觉反馈与DOM更新节奏，对齐60fps刷新周期；dragover仅轻量采样坐标并缓存，避免同步布局触发。
节流在鼠标拖拽和元素位置计算中，不是用来“压低 dragover 触发频率”，而是用来协调视觉反馈与 DOM 更新节奏，让关键计算对齐浏览器 16.7ms（60fps）刷新周期，避免 layout thrashing 和卡顿。
dragover 中只做轻量坐标采样，不触发重排
dragover 本身已按帧率节流（约每 16.7ms 一次），无需额外 throttle。重点是：每次触发时，只读取 event.clientX/clientY，缓存到变量，不做 DOM 查询、getBoundingClientRect() 或样式修改。
- 提取坐标后立即存入局部变量，如
currentX = e.clientX; currentY = e.clientY; - 避免在 dragover 里调用
element.getBoundingClientRect()——它会强制同步布局，打断渲染流水线 - 若需判断悬停区域，提前缓存目标元素的 bounding rect，并用数学方式比对（如
currentX > left && currentX ）
用 requestAnimationFrame 批量更新 UI 反馈
把坐标采样和 UI 反馈解耦：dragover 负责采集，rAF 负责渲染。这样既能保持响应连续性，又确保 DOM 更新严格对齐帧节奏。
- 声明一个
pendingUpdate = false标志，dragover 中设为 true 并调用requestAnimationFrame(updatePreview) -
updatePreview函数内执行所有视觉操作：移动预览图、高亮插入线、更新透明度等 - rAF 自动对齐 16.7ms 帧间隔，且浏览器会合并多次 DOM 写入，避免重复重排
插入点计算用防抖，而非节流
确定元素插入位置（如 list 中的 index）属于耗时逻辑，不适合高频执行。它不需每帧更新，只需在用户拖拽暂稳时精准算一次。
- 对插入点计算函数用 debounce(50ms) 包裹，而不是 throttle
- 理由：用户拖动时位置持续变化，中间状态无意义；只有当鼠标暂停约 50ms，才代表意图明确，此时再遍历列表找最邻近项
- 避免在 dragover 中反复调用
Array.from(items).findIndex(...)这类操作
真实 DOM 移动只发生在 drop 或 dragend
拖拽过程中的所有 DOM 操作（appendChild、insertBefore、remove）必须延迟到最终落点确认后再执行。这是性能与逻辑正确的双重保障。
- dragover 阶段只维护一个
hoverTarget变量，记录当前悬停的容器或索引 - drop 事件中检查
e.dataTransfer.dropEffect === 'move'，再执行真实 DOM 移动 - dragend 中统一清理临时状态（如移除高亮边框、还原 opacity），不依赖 dragover 中间态
