z-index失效的根本原因是元素未进入同一层叠上下文；需确保目标元素已定位（position非static），并排查祖先节点是否因opacity
定位元素层级显示错误，根本不是 z-index 数值不够大，而是它压根没进同一个比较场——z-index 只在同层叠上下文内生效，一旦父级悄悄创建了新上下文，子元素的 z-index 就被“关小黑屋”了。
为什么加了 z-index 还是被盖住？
最常见的情况：目标元素写了 z-index: 100，但它的某个祖先节点有 opacity: 0.99、transform: translateZ(0)、filter: blur(1px) 或 will-change: transform。这些属性会隐式创建新的层叠上下文，导致该祖先以下的所有 z-index 都只在它内部比大小，和外部元素完全无关。
- 用 Chrome DevTools 的「Computed」面板检查目标元素，搜
stacking context，看是否被标记为 “Yes” - 逐级向上检查父元素的
position、opacity、transform、filter、will-change等属性 - 临时删掉疑似父容器的
transform或opacity，看层级是否立刻恢复正常
absolute 元素突然飞到页面左上角
这不是 top 和 left 写错了，而是它找不到参考系——position: absolute 会向上查找**最近的非 static 定位祖先**作为包含块（containing block）。如果所有父级都是 position: static（即默认值），它就直接相对于 viewport 定位。
- 打开 DevTools，选中错位元素，在「Computed」面板里找
Containing block字段，看它实际绑定的是哪个节点 - 在 Elements 面板里从父节点开始逐级点开，看哪个节点的
position是relative、absolute或fixed - 若预期父容器没设定位，就给它加
position: relative（不带偏移也行），让它成为合法参考系
移动端 Safari 中 z-index + transform 组合失效
iOS Safari 对 transform 和 z-index 的配合特别敏感：只要父容器用了 transform（哪怕只是 translateZ(0)），又没显式声明 z-index，其子元素即使设了 z-index，也可能被渲染到错误层级。
- 最稳妥解法：在触发
transform的父容器上，**同时加position: relative和z-index: 0** - 避免仅靠
transform触发硬件加速却不设z-index，这在 Safari 下等于埋雷 - 测试时务必真机验证，模拟器有时无法复现该问题
怎么组织 z-index 才不翻车？
硬写 z-index: 9999 是在给未来挖坑。真正可维护的方式是语义化分层 + CSS 自定义属性统一管理。
- 在
:root中定义层级变量：--z-header: 100、--z-dropdown: 200、--z-modal: 1000、--z-toast: 1100 - 组件内用
z-index: var(--z-modal)，而不是散落在各处的魔法数字 - 相邻层级留出足够空隙（比如间隔 100），方便后续插入新类型组件
- 注意：负
z-index会让元素无法响应鼠标事件，如需点击，得额外加pointer-events: auto
层级问题最难 debug 的地方，往往不在目标元素本身，而在它上方两三级的某个“安静”的父容器——那个写了 opacity: 0.99 或 transform: scale(1) 却没人记得的节点，才是真正的结界制造者。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
