z-index 无效的根源在于元素未定位或被父级堆叠上下文隔离；需确保 position 非 static、避免意外触发 stacking context，并通过 devtools 的 layers 和 computed 面板调试上下文层级。
z-index 不是“写上就上”的开关，它只在元素已定位且未被父级堆叠上下文隔离时才起作用；绝大多数层级失效问题，根源不在数字大小，而在 position 缺失或 stacking context 被意外触发。
为什么写了 z-index 却完全没反应？
最常见原因是目标元素的 position 仍是 static（默认值）。CSS 规范明确限定：z-index 对 position: static 元素无效。
- 检查开发者工具「Computed」面板，确认
position的最终计算值不是static，且z-index显示为具体数字（而非auto） - 框架中（如 Vue/React）内联样式或 CSS-in-JS 可能覆盖你写的
position，导致z-index形同虚设 -
flex或grid容器的直接子项虽支持z-index，但一旦子项内部再用position: absolute，其后代必须自己声明position才能启用z-index
为什么 z-index: 9999 还是被 z-index: 1 盖住？
这不是数值输了，而是它们根本不在同一个比较场——父容器悄悄创建了独立的 stacking context，把子元素锁在“小房间”里比大小。
- 触发新 stacking context 的常见属性：
opacity: 0.99、transform: translateZ(0)、filter: blur(1px)、will-change: transform、isolation: isolate - iOS Safari 对
transform和will-change极其敏感，哪怕只为硬件加速，也可能意外创建上下文 - 调试方法：Chrome DevTools → 「Layers」面板查看上下文边界；或临时注释掉父级可疑属性，看层级是否恢复
如何让弹窗、遮罩等浮层真正“浮起来”？
靠堆高 z-index 数字是治标不治本。更可靠的做法是脱离原有 DOM 嵌套链，从结构上规避 stacking context 隔离。
- 把
modal、toast、overlay等浮层元素用 JavaScriptappendChild到document.body底部——天然脱离父级上下文，只依赖 DOM 顺序和自身z-index - 若必须嵌套在某容器中，确保遮罩层与弹窗处于同一 stacking context 根下（例如共用一个
position: fixed; z-index: 1000的父容器） - 移动端尤其注意：
position: fixed元素在 iOS Safari 中会自动创建 stacking context，且默认层级高于普通absolute元素，不要把遮罩层和弹窗分开放在不同 fixed 容器里
数值该设多少才不踩坑？
数值本身没有魔法，但乱设会掩盖结构问题。关键是预留梯度、避免负值、拒绝魔数。
- 别用
z-index: 999999或2147483647—— 旧版浏览器可能溢出，也掩盖了 stacking context 设计缺陷 - 按功能分段预留空档：
--z-toast: 100、--z-dropdown: 200、--z-modal: 1000，用 CSS 自定义属性统一管理 - 避免
z-index: -1：它会让元素沉到父容器背景色之下，如果父容器有背景或边框，就直接看不见了 - 同级定位元素
z-index相同时，谁在上面取决于 HTML 中的 DOM 顺序——靠后的那个显示在前面
真正难调的从来不是数字，而是搞清当前元素嵌在哪几层 stacking context 里；浏览器 DevTools 的「Layers」面板和「Computed」里的 stacking context 提示，比反复改数字靠谱得多。最容易被忽略的，是以为在调一个按钮的层级，其实是在调试整棵上下文嵌套链。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
