z-index不生效主因是元素未创建层叠上下文；需设position为relative/absolute/fixed/sticky才启用，且受父级opacity/transform等属性意外创建的上下文限制。
z-index 不生效？先确认元素是否进入定位上下文
很多情况下 z-index 看似写了但完全没反应，根本原因不是写错了值，而是该元素压根没创建自己的层叠上下文（stacking context）。只有 position 值为 relative、absolute、fixed 或 sticky 时，z-index 才会起作用。
常见错误现象：div 默认是 static 定位，此时设 z-index: 999 无效；父容器用了 transform 或 opacity 等属性，意外创建了新层叠上下文，导致子元素的 z-index 只在该上下文内比较，无法越过父级去和兄弟元素比高低。
- 必须显式设置
position（哪怕只是position: relative）才能激活z-index - 检查父级是否无意中触发了层叠上下文（如
opacity: 0.99、will-change: transform、filter: blur(1px)） - 浏览器 DevTools 的 Layers 面板可直观查看层叠上下文边界
z-index 数值怎么选：相对性远比绝对值重要
z-index 的作用域永远是「同层叠上下文内的兄弟元素」。它不保证全局最高，只决定“在谁上面”。比如两个独立的 position: relative 容器，各自内部的 z-index: 999 互不影响——谁在 DOM 里靠后、谁的层叠上下文更“高”，才真正决定最终显示顺序。
使用场景：模态框（modal）常需要盖住所有内容，但若直接写 z-index: 999999，反而容易被更高层上下文里的 z-index: 1 盖过。
立即学习“前端免费学习笔记（深入）”；
- 优先用小整数（如
1、10、100），留出扩展余地 - 整个项目建议定义层级常量（如 CSS 自定义属性
--z-modal: 1000），避免魔法数字 - 不要迷信大数字，
z-index: 2在它的上下文里可能比另一个上下文里的z-index: 9999更靠前
flex / grid 子项的 z-index 行为特殊吗？
Flex 容器或 Grid 容器的直接子项，即使没有 position，也能响应 z-index ——这是 CSS Flexbox 和 Grid 规范的明确例外。但它仅限于「第一层子元素」，且只影响它们在 flex/grid 轴向布局中的绘制顺序，不改变层叠上下文的创建规则。
容易踩的坑：给 flex 子项设了 z-index，但它的某个后代又加了 position: absolute，这时后代的 z-index 就要重新看它自己的定位上下文，跟父 flex 无关了。
- flex/grid 子项支持
z-index是特例，不是通用规则 - 一旦子项内部再定位（如
position: absolute），其后代的层叠行为回归标准规则 - 若需跨层级控制，仍需靠父容器创建可控的层叠上下文
移动端 Safari 对 z-index 的兼容细节
iOS Safari（尤其旧版本）对层叠上下文的触发更敏感。比如 backface-visibility: hidden 或 transform: translateZ(0) 在其他浏览器里只是优化渲染，在 Safari 里却可能意外创建新层叠上下文，把本该浮在顶部的弹窗“关”进局部层级里。
性能影响：频繁强制创建层叠上下文（尤其是通过 transform 或 opacity）会增加合成图层数量，拖慢滚动和动画表现。
- 调试时可在 Safari 开发者工具中勾选 “Show Paint Rects”，观察图层切分是否异常
- 避免在滚动容器上滥用
will-change: transform，它极易引发意料外的层叠隔离 - 真机测试比模拟器更可靠，特别是 iOS 15 以下版本对
z-index的解析有已知偏差
z-index，而是花半小时才发现某个祖先元素悄悄加了 opacity: 0.999 ——它不显眼，但足以把整个模块锁进一个独立的绘制层里。 
