z-index仅对position为relative、absolute、fixed或sticky的元素生效；父元素触发层叠上下文会限制子元素z-index作用范围；浮动元素需加position才参与z-index排序；子元素z-index再大也无法超越父级层叠层级。
元素没设 position，z-index 就是摆设
这是最常踩的坑：写了 z-index: 999，但元素还是被盖住——打开开发者工具一看，position 是默认的 static。CSS 规定：z-index 只对 position 值为 relative、absolute、fixed 或 sticky 的元素生效，其余一律忽略。
- ✅ 正确写法：
.modal { position: fixed; z-index: 1000; } - ❌ 错误写法：
.modal { z-index: 1000; } /* 缺少 position，z-index 被浏览器直接丢弃 */ - 注意：即使父容器有定位，子元素也必须自己声明
position才能参与层叠排序
父元素偷偷创建了层叠上下文
你以为子元素 z-index: 9999 很高，结果它只在父容器“内部楼层”里最高——出不去。这是因为父元素触发了层叠上下文（stacking context），比如加了 opacity: 0.99、transform: scale(1)、filter: blur(0)，哪怕只是 position: relative + z-index: 0，也会形成独立“Z轴宇宙”。
- 现象：两个同级弹窗，一个能盖住另一个，但它的子元素却盖不住另一个弹窗的子元素
- 调试技巧：Chrome 开发者工具 → Layers 面板 → 点击元素看 “Stacking Context” 是否被标记为 root
- 修复方向：
– 移除父元素的opacity/transform等隐式触发属性
– 把需要高优先级的元素（如遮罩层）提到更外层 DOM 结构中
– 或确保所有竞争元素处于同一层叠上下文（例如统一给父容器设position: relative; z-index: 0）
float 和 z-index 是“死对头”
一旦元素设置了 float（比如 float: left），又没配 position，那它就属于“普通流中的浮动元素”，压根不进 z-index 排序队列——层叠顺序规则里它排在负 z-index 定位元素之后、块级非定位元素之前，z-index 对它完全无效。
- 典型错误结构：@@##@@
- 三种可靠解法（任选其一）：
– 给浮动元素加上position: relative
– 把父容器的position: relative改成position: absolute
– 直接去掉float，改用display: flex或grid布局
z-index 数值再大，也跨不过父级的“天花板”
假设 .A 和 .B 是同级容器，.A 的 z-index: 1，.B 的 z-index: 2；那么无论 .A > .child 设成 9999，它也永远盖不住 .B 或 .B > .inner——因为层叠比较发生在父级之间，子级只能在自己父容器划定的“楼层区间”里排序。
立即学习“前端免费学习笔记（深入）”；
- 关键判断点：检查你试图覆盖的目标元素，是否和它“真正对手”的父容器处于同一层级？
- 实操建议：
– 查看目标元素及其对手的最近公共祖先是否已设定位+z-index
– 如果涉及第三方组件（如 UI 库弹窗），优先查它外层 wrapper 的z-index计算值（开发者工具里看 Computed 样式）
– 必要时全局统一 z-index 基线（例如定义 CSS 变量：:root { --z-modal: 1000; --z-tooltip: 1050; }）
层叠上下文不是玄学，但它确实不按直觉运行——你看到的“谁在上”，本质是浏览器按一套严格规则逐层计算出来的结果。别盲目调高数字，先确认定位、再检查上下文、最后比对父级层级，三步走完，90% 的 z-index 失效问题就解开了。
