应放弃 grid-template-areas，改用 grid-row / grid-column 显式控制元素位置，拖拽时仅更新 CSS 自定义属性并动态写入样式，避免 DOM 移动导致区域错位。
拖拽时 grid-template-areas 被破坏怎么办
直接用 grid-template-areas 定义布局后，拖拽元素会导致区域名错位甚至丢失——因为该属性依赖静态字符串映射，不响应 DOM 位置变化。实际中只要元素被 appendChild 或 insertBefore 移动，area 名就和真实位置脱钩。
正确做法是放弃 grid-template-areas，改用 grid-row / grid-column 控制单个元素位置：
- 初始渲染时为每个子项设置唯一
data-index，并按顺序分配grid-row: 1; grid-column: 1;等显式坐标 - 拖拽结束时，不移动 DOM 元素，而是更新其
grid-row和grid-column的 CSS 自定义属性（如--row、--col），再通过style动态写入 - 避免用
order属性排序：它只影响视觉顺序，不改变网格轨道占用，易引发重叠或空洞
如何让拖拽反馈与 Grid 轨道对齐
原生 dragover 事件的 clientX/clientY 坐标无法直接映射到 grid 轨道索引，尤其在有 gap、scroll、缩放时误差明显。
可靠方案是监听 dragenter 并结合 getBoundingClientRect() 计算目标轨道：
立即学习“前端免费学习笔记（深入）”；
- 预先缓存所有 grid item 的
boundingClientRect，按top+height划分行轨道，按left+width划分列轨道 - 在
dragenter中遍历轨道边界，用event.clientY找最近行，event.clientX找最近列 - 用
document.elementFromPoint()辅助校验——但注意它可能返回父容器，需加pointer-events: none过滤非目标元素
示例逻辑片段：
const rect = gridContainer.getBoundingClientRect(); const row = Math.floor((e.clientY - rect.top) / (itemHeight + gap)); const col = Math.floor((e.clientX - rect.left) / (itemWidth + gap));
Grid 拖拽排序的性能瓶颈在哪
高频触发的 drag 事件里做 DOM 查询或样式计算会卡顿，尤其 grid item 超过 20 个时。
关键优化点：
- 把
getBoundingClientRect()结果缓存为数组，仅在窗口 resize 或内容变更时重算 - 用
requestAnimationFrame节流drag中的位置更新，避免每帧都重排 - 避免在拖拽中调用
getComputedStyle()—— 改用预设的itemHeight/itemWidth常量，或 CSS 自定义属性读取 - grid container 设置
contain: layout style，限制浏览器重排范围
移动端 Safari 的 Grid 拖拽兼容性问题
iOS 16.4+ 才支持 drag API 在非 a、img 元素上触发；且 Safari 对 grid-row 动态更新有 1–2 帧延迟，导致视觉跳变。
兜底策略：
- 检测
'draggable' in document.createElement('span')，不支持则降级为 touchmove + transform 模拟拖拽 - 对 Safari 加
-webkit-grid-row和-webkit-grid-column双写，确保生效 - 拖拽中临时给被拖元素加
position: fixed+z-index: 9999，绕过 grid 渲染层干扰
真正麻烦的是 grid track sizing 依赖内容高度时——Safari 会因 fixed 定位导致行高塌陷，必须提前用 min-height 锁死轨道尺寸。
