z-index不生效的根本原因是元素未参与层叠上下文；只有定位元素且自身或祖先触发了层叠上下文，z-index才起作用，常见坑点包括position:static、意外创建上下文（如opacity、transform）、父容器filter干扰等。
z-index 不生效？先确认元素是否“参与层叠”
很多情况下 z-index 看似写了却没用，根本不是值设小了，而是父容器没触发层叠上下文（stacking context）。只有定位元素（position 为 relative、absolute、fixed 或 sticky）且自身或祖先建立了层叠上下文，z-index 才真正起作用。
常见踩坑点：
-
position: static元素无视z-index（这是默认值，最容易忽略） - 父级用了
opacity: 0.99、transform: translateZ(0)、will-change: transform等，会意外创建新层叠上下文，把子元素的z-index“关进小黑屋” - 两个同级元素，一个有
z-index: 10，另一个没设z-index（即auto），后者在层叠顺序中默认低于前者——但若后者父容器新建了层叠上下文，它整个子树就可能整体浮到前面
负 margin 拉近重叠距离时，别碰文档流“地基”
margin-top: -20px 或 margin-left: -16px 是快速实现视觉重叠最轻量的方式，但它不改变元素在文档流中的原始占位。这意味着：
- 后续兄弟元素仍按“原位置”布局，不会因为上面元素被负 margin 上提而自动跟上——容易造成意料外的空白或遮挡
- 如果负 margin 过大（比如
margin-top: -1000px），可能让元素脱离可访问区域，影响屏幕阅读器或 :focus-visible 行为 - 和
transform: translateY(-20px)不同，负 margin 会触发布局重排（reflow），而 transform 只触发重绘（repaint），高频动画场景慎用
z-index 和负 margin 混用时的层级优先级陷阱
当一个元素既设了 z-index 又用了 margin-top: -10px，它的层叠顺序只由 z-index 决定；但它的“邻居”是否能盖住它，取决于双方所处的层叠上下文是否同一层。真实项目中最常出问题的是菜单弹层 + 卡片列表组合：
立即学习“前端免费学习笔记（深入）”；
- 卡片用
position: relative+z-index: 1，弹层用position: absolute+z-index: 1000，看似没问题 - 但如果卡片容器加了
filter: drop-shadow(...)，它就悄悄成了新层叠上下文，弹层即使z-index: 9999也出不来——因为它的“1000”是相对于卡片容器算的，不是全局 - 此时要么去掉容器的 filter，要么把弹层挂到
body下（脱离原上下文），或者给容器也设z-index: 0显式建立上下文并统一管理
移动端 Safari 对 z-index 的特殊限制
iOS 15+ 的 Safari 在某些复合层叠场景下（比如 position: fixed + transform + z-index 同时存在），会强制将 z-index 值截断为 2^23（约 838 万）以内，超出部分等同于最大值。更隐蔽的是：它对 will-change: opacity 创建的层叠上下文处理不稳定，可能导致本该在顶层的弹窗被 iframe 或 video 盖住。
实操建议：
- 避免无意义的
will-change，尤其别对整页容器滥用 - 固定定位弹层务必加
transform: translateZ(0)强制提升为合成层，比单靠z-index更可靠 - 测试时真机连 Safari Web Inspector，用“Layers”面板直接看层叠结构，比猜强得多
层叠逻辑从来不是简单的数字比大小，而是上下文套娃 + 渲染管线干预的结果。调的时候多看 computed styles 里的 “Stacking Context” 标记，比反复改 z-index: 999999 有用得多。
