z-index无效首要原因是元素未显式设置position（必须为relative/absolute/fixed/sticky），其次因父级触发层叠上下文（如opacity
z-index写上却没反应？先看position有没有显式声明
绝大多数“z-index失效”根本不是数值问题，而是元素压根没进入定位上下文。浏览器只认 position: relative、position: absolute、position: fixed 或 position: sticky 的元素，其余一律忽略 z-index。
-
position: static（默认值）下写z-index: 9999等同于没写，DevTools 中该属性会灰显或标为(not applicable) - 别指望父级设了
position: relative就能让子元素“自动定位”——子元素自己必须显式声明position -
position: sticky在滚动边界外会退化为relative，此时z-index行为可能突变，尤其在 iOS Safari 上更不稳定
为什么两个z-index一大一小，小的反而盖住了大的？
这不是数值比大小，而是它们被分到了不同“行政辖区”——即不同的堆叠上下文（stacking context）。父级一旦触发新上下文，子元素的 z-index 就只能在内部排序，跨不出去。
- 常见触发父级新建上下文的操作：
opacity: 0.99、transform: translateZ(0)、filter: blur(1px)、will-change: transform、isolation: isolate - 哪怕只是
position: relative; z-index: 0，也会创建新上下文——很多人误以为z-index: 0是“不设”，其实它是明确的非auto值 - 用 Chrome DevTools 的「Computed」面板搜索
Stacking Context，能直接看到哪个祖先节点标着 “This element establishes a stacking context” - 临时验证：注释掉可疑父级的
transform或opacity，观察子元素是否立刻“浮上来”
父子元素z-index谁说了算？别被视觉误导
子元素永远在父元素之上，但它的“上限”由父容器所在上下文决定。父级层级低，子再高也出不去——这和文档流嵌套逻辑一致，不是 bug，是规范。
- 若 A 和 B 是同级元素，A 的
z-index: 100，B 包在一个z-index: 10的容器里，那整个 B 子树都会被压在 A 下面 - 子元素的
z-index只影响它和兄弟元素的顺序，不改变父容器在外部的层级位置 - 模态框、下拉菜单这类需全局覆盖的组件，建议挂到
直接子级，绕过中间嵌套的“隔离卡” - iframe 是独立文档环境，其渲染层天然高于普通 DOM；想遮盖它，遮罩层必须与 iframe 同级，且其父容器要有更高堆叠优先级
怎么让z-index管理不再靠猜和堆数字？
靠 z-index: 999999 解决不了问题，只会让后续覆盖更难协调。真正要管的是结构，不是数字本身。
- 用语义化常量替代魔数：Sass 中定义
$z-modal: 1050、$z-dropdown: 900，CSS-in-JS 或 Tailwind 项目也应同步维护 JS 端常量对象 - 按功能划分区间，留余量：
-10 ~ 0（遮罩背景）、100 ~ 199（导航栏）、1000 ~ 1999（浮层），避免后期扩展时撞车 - 关键浮层统一加 class（如
class="js-z-modal"），配合:root自定义属性集中调控：--z-modal: 1050 - 调试时打开 Chrome DevTools → More Tools → Layers 面板，直观查看实际渲染层级分组，比反复改 CSS 快得多
最容易被忽略的，是以为在调一个按钮的层级，其实是在调试从目标元素往上逐层的堆叠上下文链——那个悄悄加了 transform 的祖父容器，才是真正的“小 boss”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
