z-index仅对position为relative、absolute、fixed或sticky的定位元素生效；若元素为static（默认）则z-index被完全忽略，且父级创建层叠上下文时子元素z-index仅在内部有效。
z-index 不是写上就生效的属性，它只对已定位元素起作用。如果你给一个普通 div 直接加 z-index: 999 却没效果，大概率是因为漏了 position。
必须先设 position 才能用 z-index
浏览器只认「定位元素」的 z-index。所谓定位元素，是指 position 值为 relative、absolute、fixed 或 sticky 的元素。
- 写
position: static（默认值）或完全不写position，z-index会被忽略 -
position: relative最常用：不脱离文档流，适合微调+层级控制 -
position: absolute适合弹窗、提示框等需脱离流的场景，但要注意父容器是否带position - 别用
position: absolute布局整页——响应式会崩，且容易触发意外堆叠上下文
为什么两个 z-index 数值一大一小，还是被盖住？
问题不在数值本身，而在它们是否属于同一个堆叠上下文（stacking context）。父级一旦创建了独立堆叠上下文，子元素的 z-index 就只在内部比大小，跨父级无效。
- 常见触发父级新建堆叠上下文的操作：
position: relative+z-index（非auto）、opacity: 0.99、transform: translateZ(0)、will-change: transform - 排查方法：打开开发者工具 → 「Computed」面板 → 搜索
z-index和stacking context，看是否标出「Stacking Context」 - 临时验证：把疑似父容器的
opacity或transform注释掉，观察层级是否恢复正常
iOS Safari 和 iframe 的特殊限制
移动端和嵌入场景下，z-index 表现更易出错，不是 bug，是规范行为。
- iOS Safari 对
transform: translateZ(0)或will-change: transform极其敏感，哪怕只是为了开启硬件加速，也可能意外创建新堆叠上下文，让某个按钮“突然浮到最上面” -
iframe内部是一个完全独立的文档环境，它的z-index与父页面毫无关系；你无法用父页的z-index把遮罩层盖在iframe上面 - 如果必须覆盖
iframe，只能在iframe同级 DOM 层级插入元素，并确保该元素的父容器有更高堆叠上下文优先级
真正决定渲染顺序的，不是 z-index 数字本身，而是浏览器构建的堆叠上下文树。数值只是同一上下文内的排序依据。很多人卡在“为什么我写了 9999 还是压不住别人”，其实该查的是谁悄悄当了“小 boss”——那个创建了局部堆叠上下文的父容器。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
