z-index不生效的根本原因是元素未处于层叠上下文中；只有在层叠上下文内部，z-index才决定子元素堆叠顺序，跨上下文时父级整体层级优先。
z-index 不生效？先确认是否创建了层叠上下文
很多情况下 z-index 看似“失效”，其实是它根本没起作用——因为目标元素没处在自己的层叠上下文中。只有在层叠上下文内部，z-index 才能决定子元素的堆叠顺序；跨上下文时，父级上下文的整体层级优先于子级的 z-index 值。
触发层叠上下文的常见方式包括：position 非 static 且设置了 z-index（非 auto）、opacity 小于 1、transform 不为 none、filter 不为 none、will-change 指定相关属性等。注意：仅 position: relative + z-index: auto 不会创建新上下文。
-
z-index只对定位元素（position为relative/absolute/fixed/sticky）有效 - 父容器若已建立层叠上下文（比如用了
transform: translateZ(0)），其子元素的z-index只在这个父容器内比较，无法盖过兄弟容器 - Chrome DevTools 的 Layers 面板可直观查看层叠上下文树，比猜更可靠
同级元素 z-index 数值越大就一定越靠前？
不一定。数值只在**同一层叠上下文内**有意义。两个同级 div，如果各自父容器都创建了独立的层叠上下文，那么谁在上面，取决于这两个父容器自身的堆叠顺序——而这个顺序由它们在 DOM 中的顺序、是否定位、是否设了 z-index 等共同决定，跟子元素的 z-index 无关。
典型反例：div#header 和 div#modal 是兄弟节点，#modal 内部有个 z-index: 9999 的按钮，但 #header 自身有 z-index: 100 且建立了上下文，而 #modal 是 static，那按钮依然会被 #header 盖住。
立即学习“前端免费学习笔记（深入）”；
- 浏览器按 DOM 顺序和层叠上下文生成“层叠级别（stacking level）”，不是简单比数字
-
z-index: 9999的元素，可能被一个z-index: 1但处于更高层叠上下文的父容器整体压住 - 避免嵌套多层带
z-index的定位容器，容易失控；模态框这类组件建议直接挂到body下
transform 或 opacity 导致 z-index 行为异常
只要给元素加了 transform: translateX(0) 或 opacity: 0.99，它就会隐式创建新的层叠上下文——哪怕你没写 z-index。这常导致原本预期平级的兄弟元素突然“分层”，z-index 对不上号。
例如：一个轮播图容器用了 transform: translateZ(0) 提升性能，结果里面的 button 死活盖不到隔壁导航栏上，就是因为轮播图自己成了独立上下文，它的整个内容块被当作一个整体参与外层堆叠。
- 用
transform或opacity做动画时，要同步检查是否意外隔离了堆叠关系 - 调试技巧：临时删掉
transform/opacity，看z-index是否恢复预期行为 - 真需要硬件加速又不想建上下文？可用
will-change: transform替代直接写transform，它不强制创建上下文（但需谨慎使用）
移动端 Safari 的 z-index 兼容陷阱
iOS Safari 对层叠上下文更敏感，尤其在 position: fixed 和 transform 共存时。一个常见现象是：页面滚动时，带 transform 的弹窗内容突然被 fixed 头部遮挡，即使弹窗的 z-index 更高——这是因为 Safari 把 fixed 元素和某些 transform 元素分别放入不同合成层，且未严格按规范处理上下文层级。
- iOS 15+ 修复了部分问题，但低版本仍存在；测试必须真机，模拟器不可靠
- 避免对
fixed容器内部元素使用transform，宁可用top/left动画 - 极端情况可加
-webkit-transform: translateZ(0)到父级fixed元素，强制它进入更高优先级合成层（副作用是内存占用略增）
层叠上下文不是开关，是嵌套结构；每次加 z-index 或视觉属性前，得先想清楚：我在哪一层里，谁在管这一层的顺序。
