html z-index层级堆叠规则
z-index 调成 9999 依然失效？真正卡住你的不是数值，是这个机制
前端开发里有个经典场面：你想弹出一个遮罩层，把背景盖得严严实实，于是随手给元素加上 z-index: 9999。结果刷新页面一看，该挡住的导航栏或者兄弟元素依旧浮在上面。
很多小伙伴第一反应是怀疑人生，觉得是不是浏览器 Bug，或者自己的代码写错了。其实，问题通常不出在数值大小上，而是你掉进了“堆叠上下文（Stacking Context）”的坑里。
别只看分数，先看“考场”
理解 z-index 最关键的一点在于：它不是全局排名的考卷，而是小组内部的评分。
想象一下公司里有不同的部门，每个部门有自己的排名。一个 A 部门得分 90 分的人，不一定能压过 B 部门得分 80 分的人，因为他们在不同的汇报体系下。CSS 中的堆叠上下文就是这个“部门”。只有当两个元素处于同一个上下文里时，比较 z-index 的大小才有意义；如果它们不在同一个上下文里，谁的数值大根本决定不了谁在上面。
这就解释了为什么你把子元素的值设得天花乱坠，却盖不住父容器外部的某个东西——因为它俩压根不在一个“组”里。
哪些属性会意外创建“新部门”？
既然是部门独立排名，那么了解谁有权建立新部门就至关重要。除了大家熟知的 position 为非 static 且设置 z-index 之外，还有很多隐蔽的属性会触发新的堆叠上下文，这也是新手容易忽略的地方：
- opacity 小于 1：哪怕透明度只降低了一点点，比如 0.99，这个元素也会变成一个新的上下文根节点。
- transform 非 none：只要加了一个位移或缩放，层级就可能被隔离。
- filter 滤镜效果：应用模糊或色彩滤镜时，同样会切断层级继承。
- flex/gird 容器的子项：如果父级是 Flex 布局且设置了
z-index，子元素的z-index也可能受限于此。
当你发现样式无法穿透时，不要盲目增大数值，先用开发者工具 inspect 检查父元素是否无意中触发了上述条件。有时候只是一个为了微调位置加的 transform: translateZ(0)，就把整个层级关系给锁死了。
实操中的避坑指南
遇到层级打架的情况，按这个思路排查通常能解决 90% 的问题。
如果是弹窗盖不住全屏背景，检查一下最外层容器是否包含了其他高权重的定位元素。常见的做法是将需要置顶的元素移出复杂的嵌套结构，放到更靠近 <body> 的位置。虽然这听起来有点粗暴，但在现代框架组件化开发中，将全局弹窗挂载到 DOM 树根部确实是最稳妥的方案。
如果是浮动菜单被内容遮挡，试试提升父级容器的层级。既然子元素再努力也出不去父级“办公室”，那不如把整个办公室搬到楼上。调整父元素的 position 和 z-index，往往比直接攻击子元素有效得多。
另外，慎用负数。z-index: -1 理论上会让元素沉到底部，但如果在没有明确上下文的块级元素上使用，可能会被默认的文档流逻辑吞噬，导致点不到事件。
总结
写 CSS 就像搭积木，z-index 只是告诉你哪块积木应该放上面，但前提是你得保证这些积木放在同一个桌子上。
下次再看到层级冲突，先停下修改数字的手，退一步审视 DOM 结构和属性影响。与其追求无限大的 z-index，不如理清堆叠上下文的边界。 这种对渲染机制的理解，比单纯记住几个属性值更有价值，也能让你在面对复杂交互布局时少踩不少坑。
还没有评论，来说两句吧...