z-index不生效的根本原因是元素未定位或被父级层叠上下文截断；必须设置position为relative/absolute/fixed/sticky，且需确保父子在同一层叠上下文中。
z-index 不生效？先确认元素是否“定位了”
很多情况下设了 z-index 却没反应，根本原因不是值写错了，而是该元素压根没进入层叠上下文——z-index 只对定位元素（position 为 relative、absolute、fixed 或 sticky）起作用。
常见错误现象：div 直接写 z-index: 999;，但没加 position: relative;，结果完全无效。
- 必须显式设置
position，哪怕只是position: relative;且不偏移 -
position: static（默认值）下z-index被忽略，浏览器直接当不存在 - Flex 或 Grid 容器的子项即使有
z-index，若自身未定位，也不参与层叠顺序计算
父容器的 stacking context 会截断 z-index 的影响范围
子元素的 z-index 永远只在父级层叠上下文中比较。一旦父元素自己成了新的 stacking context（比如设置了 opacity: 0.99、transform: translateZ(0)、will-change: transform，或带 z-index 的定位元素），它的所有子元素就被“关进小房间”，再大的 z-index 也出不去。
使用场景：模态框（modal）盖不住某个带 transform 的轮播图？大概率是轮播图父容器意外创建了 stacking context。
立即学习“前端免费学习笔记（深入）”；
- 检查父级是否用了
opacity小于 1、filter、transform、will-change等触发 stacking context 的属性 - 用浏览器开发者工具的“Layers”面板（Chrome）或“Computed”中查看
stacking context标记 - 临时移除父级的
transform或opacity，看子元素z-index是否恢复作用
z-index 数值比较只在同一 stacking context 内有效
两个元素不在同一个层叠上下文里，数值大小毫无可比性。比如 A 在 body 下（根 stacking context），B 在一个 z-index: 10 的弹窗内部，那 B 即使设 z-index: 9999，也永远盖不过 A——因为 A 所在的上下文整体层级就比弹窗高。
性能影响：频繁创建 stacking context（如给大量元素加 transform）可能增加合成层数量，间接影响渲染性能。
- 不要迷信“只要 z-index 够大就能盖住一切”，得看它们是不是“同一屋檐下”
- 想让某组件全局置顶（如 toast 提示），最好让它挂到
body下，避免嵌套过深导致被父 context 截断 - 调试时可用
getComputedStyle(el).zIndex查实际解析值，注意返回字符串（如"auto"）
auto 和 0 的区别经常被忽略
z-index: auto 不等于 0。它表示该元素不创建新的 stacking context，且在当前上下文中按文档流顺序参与层叠（通常排在有明确 z-index 值的兄弟元素之后）。
容易踩的坑：把弹窗的遮罩层设成 z-index: auto，而内容层设 z-index: 1，结果遮罩反而在内容后面——因为 auto 在层叠顺序中默认靠后。
- 遮罩层和内容层应同属一个父容器，且都显式定位；遮罩设
z-index: 10，内容设z-index: 11 - 避免依赖
auto做层叠控制，除非你明确知道当前上下文里没有其他定位兄弟元素 - IE8 及更早版本不支持
z-index: auto，会当作0处理（但基本不用考虑了）
真正难的不是调数字，而是理清谁跟谁在一个“空间”里。浏览器渲染时的层叠逻辑是分层的，不是扁平排序——漏掉一层 stacking context，整个 z-index 就像没写一样。
