z-index不生效的根本原因是父容器创建了层叠上下文（stacking context），使子元素z-index仅在内部生效；常见触发条件包括非static定位+数值z-index、opacity
z-index 不生效？先确认是否创建了 stacking context
很多情况下 z-index 看似写了却不起作用，根本原因不是写错了值，而是父容器悄悄创建了独立的层叠上下文（stacking context），把子元素“关进小黑屋”了。一旦某个元素成为 stacking context 的根，它的子元素的 z-index 只在这个小屋里比高低，对外部完全无效。
触发 stacking context 的常见方式包括：position 非 static + z-index 为数值（哪怕 0）、opacity 小于 1、transform 非 none、filter 非 none、will-change 指定某些属性等。移动端尤其容易因 transform: translateZ(0) 或 backface-visibility: hidden（常用于强制硬件加速）意外触发。
- 用 Chrome DevTools 的 “Layers” 面板或勾选 “Rendering > Paint flashing” + “Layer borders” 直观查看 stacking context 边界
- 检查目标元素的任意祖先是否带
opacity: 0.99、transform: scale(1)这类“看似无害”的声明 - 临时移除疑似父级的
transform或opacity，看z-index是否突然生效——这是最快速的定位手段
移动端 touch 交互时弹层被遮挡？注意 fixed 元素的 stacking context 特性
在 iOS Safari 和部分安卓 WebView 中，position: fixed 元素会自动创建 stacking context，且默认层级高于普通 position: absolute 元素。这意味着：即使你在弹窗上设了 z-index: 9999，如果它父级是 fixed 容器，而遮罩层（overlay）是直接挂 body 下的 absolute，那遮罩层很可能被压在下面。
- 避免把弹窗整个包在
position: fixed容器里；更稳妥的做法是让弹窗和遮罩层同级，都挂载到body下 - 如果必须用固定定位布局，确保遮罩层和弹窗都在同一 stacking context 内——比如给它们共同的父容器设
position: fixed; z-index: 1000，再分别设子元素z-index: 1和z-index: 2 - iOS Safari 对
fixed的处理有历史 bug，遇到滚动时弹窗错位+遮挡，可尝试加transform: translateZ(0)到弹窗本身来稳定渲染层，但要同步检查是否因此新增了嵌套 stacking context
多个 modal 嵌套时 z-index 层级混乱？别靠 magic number 硬堆
写 z-index: 999999 看似解气，实则埋雷。当业务中出现 Toast、Dropdown、Modal、Tooltip、Loading 多种浮层共存，且可能动态叠加（比如 Modal 里再打开一个 Modal），靠人工维护数字大小极易错乱，尤其跨团队组件复用时。
- 用 CSS 自定义属性统一管理：
:root { --z-toast: 100; --z-dropdown: 200; --z-modal: 300; --z-modal-overlay: 299; }，所有组件按需引用，清晰且可继承 - Modal 组件内部应主动隔离 stacking context：给 modal 根节点设
z-index: var(--z-modal)，同时设isolation: isolate（显式创建新 stacking context），防止内部子元素意外穿透影响外部层级 - 避免在子组件里擅自提升
z-index，比如 Dropdown 在 Modal 里把自己设成z-index: 9999——这会破坏 Modal 的封闭性，正确做法是 Modal 提供 zIndex prop 透传，由外层统一调度
transform 导致 z-index 失效？优先用 will-change 而非盲目加 transform
为了“优化”动画性能，很多人习惯给动效元素加 transform: translateZ(0) 或 transform: translate3d(0,0,0)。但这会强制创建 stacking context，让该元素及其后代脱离原有层叠流。尤其在移动端，这种写法泛滥，导致本该在顶部的按钮被盖住。
- 只对真正需要 GPU 加速的持续动画元素用
will-change: transform，它比硬写transform更轻量，且不会立即创建 stacking context（仅在浏览器决定优化时才触发） - 如果必须用
transform，确保它不作用在控制层级的关键父容器上——比如不要给整个.modal-wrapper加transform，而只加在内部动画卡片上 - 用
getComputedStyle(el).transform在控制台检查元素是否被意外加上了非预期的transform值（比如 JS 动画库残留）
移动端的 stacking context 是隐形的层级牢笼，不是写个大数字就能撞开的。真正麻烦的从来不是 z-index 本身，而是那些没出现在你代码里、却默默改写渲染规则的 CSS 属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
