根本原因是z-index未随拖拽实时提升，需在mousedown时用递增计数器动态设style.zIndex，并确保父容器无transform等创建新层叠上下文；移动端应改用CSS类+!important，React/Vue中宜直接操作DOM避免diff重置。
拖拽时元素突然被其他组件盖住
根本原因是 z-index 没有随拖拽实时提升，浏览器按默认文档流或静态 z-index 值渲染，导致拖拽中元素层级“卡在中间”。尤其在 React/Vue 组件嵌套深、或用了 position: fixed 的弹窗、头部导航时特别明显。
- 拖拽开始时，必须立即将目标元素的
z-index设为一个**显著高于页面常见组件**的值（比如9999），不能复用原有值 - 避免用
z-index: auto或未声明position——z-index只对position为relative、absolute、fixed、sticky的元素生效 - 若页面已存在全局模态框（如
.modal），检查其z-index基准值（常见为1050或2000），你的拖拽层至少要比它高100以上
多个可拖拽元素同时操作时 z-index 冲突
当用户快速连续拖拽不同元素（比如两个卡片），后拖的元素如果 z-index 和前一个相同，就会出现“穿插”或“叠错”的视觉 bug —— 实际是它们在同一 stacking context 里按 DOM 顺序覆盖了。
- 每次
mousedown或touchstart时，用一个递增计数器（如dragZIndexCounter）分配唯一值，而非固定值 - 不要在 CSS 里写死
z-index: 9999，务必通过 JS 动态设置：element.style.zIndex = String(++dragZIndexCounter) - 注意：若父容器设置了
transform、opacity < 1或will-change，会创建新的 stacking context，子元素的z-index只在该上下文中生效 —— 此时需确保父容器自身也有足够高的z-index
移动端 touchmove 中 z-index 失效
在 iOS Safari 或部分安卓 WebView 中，拖拽过程中频繁修改 style.zIndex 可能被节流或延迟渲染，造成“抬起后才突然上浮”的滞后感。
- 改用
element.classList.add('is-dragging')配合 CSS 规则（如.is-dragging { z-index: 9999 !important; }），比内联样式更稳定 - 确保
touchmove事件监听器添加了{ passive: false }，否则 iOS 会禁用preventDefault()，进而影响样式重绘时机 - 避免在
touchmove中做复杂计算或触发重排 ——z-index更新要轻量，最好只改一个属性
React/Vue 中动态 z-index 被框架 diff 抹掉
在组件更新时，如果 z-index 是靠 state 控制的，但拖拽状态没同步进 state（比如只存了 isDragging，没存当前层级值），下次 re-render 就会回退到初始值。
立即学习“前端免费学习笔记（深入）”；
- 把
zIndex当作受控状态管理：用useState或ref记录当前值，并在拖拽开始/结束时显式更新 - Vue 用户慎用
v-bind:style="{ zIndex }"在非根元素上——如果父组件key变了或v-if切换，整个元素可能被销毁重建，zIndex状态就丢了 - 更稳妥的做法：拖拽开始时直接操作 DOM 元素的
style.zIndex，不走响应式系统；拖拽结束再清理，绕过框架 diff 干预
z-index 不是数字越大越好，关键在 stacking context 的边界和相对顺序。很多人调到 999999 还出问题，其实是父容器早建了个独立层叠上下文，再大的子值也出不去 —— 查 DOM 结构里的 position 和 transform 才是真解法。
