原生HTML5 drag API实现网格拖拽排序需显式设draggable="true"、dragover中preventDefault()、用clientX/Y结合getBoundingClientRect()计算插入位置，并通过insertBefore()更新DOM顺序配合transform过渡动画。
怎么用原生 HTML5 drag API 实现网格项拖拽排序
原生 drag API 能做，但默认不支持“插入到两个格子之间”这种视觉反馈，必须手动计算鼠标位置与网格单元的相对关系。直接监听 dragover 并调用 event.preventDefault() 是前提，否则根本进不了拖拽流程。
常见错误是只绑了 dragstart 和 drop，漏掉 dragover 的阻止默认行为，结果拖着拖着就跳转页面或没反应。
-
draggable="true"必须显式加在每个可拖动的网格项（如<div class="grid-item">）上，仅靠 CSS <code>cursor: grab不生效 - 所有网格容器需监听
dragover并立刻执行event.preventDefault()，否则drop事件永远不会触发 - 排序逻辑不能只依赖
drop时的target，因为拖到空隙时target可能是父容器，得结合clientX/clientY和getBoundingClientRect()算落点 - 每次
drop后，先用Array.from(grid.children)获取当前顺序，算出新索引，再用grid.insertBefore(dragged, grid.children[newIndex]) - 为避免闪动，在移动前对所有子项临时加
style.transform = "translateX(0)"强制触发重排，再设回none - 不要用
grid-template-areas控制顺序——它静态且难动态更新，纯属自找麻烦 - 在
dragover里每帧都重新计算，但加防抖（如requestAnimationFrame节流），否则性能爆炸 - 如果网格是等宽高的，可用
Math.floor(clientX / itemWidth)和Math.floor(clientY / itemHeight)快速定位行列，比逐个比对快得多 - 移动端慎用 ——
drag事件在 iOS Safari 上支持极差，必须降级为touchstart/move/end模拟 - React 中禁止在
onDrop里直接操作 DOM 并期望 UI 同步，必须走setState更新数组，让框架驱动重排 - Vue 3 的
ref数组要用shallowRef或markRaw包裹拖拽项，否则响应式系统可能误触发更新 - 所有拖拽相关的 class 切换（如
is-dragging）必须通过框架绑定，而不是element.classList.add()
Grid 布局下如何让拖拽时其他项自动让位
CSS Grid 本身不响应 DOM 顺序变化带来的重排动画，order 属性或 insertBefore() 移动节点后，浏览器不会自动补间过渡。要“看起来在滑动”，得靠 transition + transform 模拟。
关键不是改 grid-area，而是保持 Grid 容器的 display: grid 不变，只用 JS 改变子元素的 DOM 顺序，并给子项加 transition: transform 0.2s ease，再配合 getComputedStyle() 触发重排后立刻设置 transform 归零。
立即学习“前端免费学习笔记（深入）”；
dragenter 和 dragover 怎么区分“悬停在格子上”和“悬停在间隙”
Grid 容器内没有“间隙元素”，所谓间隙只是子项之间的空白。判断鼠标是否落在某个具体格子上，得用 elementFromPoint(x, y)，但要注意：该方法返回的是最上层可见元素，如果格子有 pointer-events: none 或被遮挡就失效。
更稳的办法是遍历所有 .grid-item 的 getBoundingClientRect()，检查鼠标的 clientX/clientY 是否落在其范围内，并按距离排序取最近的一个。别信 event.target —— 拖拽中它常是父容器。
为什么 Vue/React 项目里直接用 drag API 很容易错乱
框架的虚拟 DOM 会拦截真实 DOM 变更。你用 insertBefore() 移动了节点，但框架下次渲染时可能按自己的数据源又把顺序刷回去，导致视觉和状态不一致。
必须同步更新框架的数据源（比如 Vue 的 ref 数组或 React 的 useState 数组），且确保 key 值稳定。拖拽结束后的数组重排不能只靠 DOM 顺序推导，得记录原始 id、目标位置，再用 splice/reorder 逻辑更新状态。
真正麻烦的不是拖拽动作本身，而是边界情况：快速连续拖拽、拖出视口、键盘辅助（Enter 触发排序）、焦点管理、无障碍标签（aria-grabbed）。这些几乎没人提，但上线后第一个被测出来。
