z-index 不生效的根本原因是元素未进入定位上下文或被父级层叠上下文截断；它仅对 position 为 relative、absolute、fixed、sticky 的元素有效，且层级由整个层叠上下文树决定，而非单纯比较数值大小。
z-index 不生效？先确认元素是否进入定位上下文
z-index 只对「定位元素」起作用，也就是 position 值为 relative、absolute、fixed 或 sticky 的元素。静态定位（position: static，默认值）下设 z-index 完全被忽略。
常见错误现象：z-index: 999 写了但完全没反应，检查发现父容器是 static，子元素虽然加了 position: relative，但被某个中间祖先的 position: relative + z-index 截断了层叠上下文——此时子元素的 z-index 只在那个祖先内部生效，无法越过它去覆盖外部兄弟元素。
- 用浏览器开发者工具检查目标元素的
computed position和z-index，确认它确实“定位”了 - 逐级向上看父级是否有创建层叠上下文（比如带
z-index的position: relative），这会形成“层叠上下文边界” - 若需全局控制层级，确保关键容器自身处于根层叠上下文（即没有意外的父级层叠上下文干扰）
为什么两个 absolute 元素，z-index 大的反而被盖住？
层叠顺序不是只看 z-index 数值大小，而是由整个「层叠上下文树」共同决定。一个 z-index: 100 的元素如果嵌套在 z-index: 1 的父容器里，它永远无法盖过同级另一个 z-index: 2 的父容器及其内容。
典型场景：弹窗组件被 Header 盖住，尽管弹窗自身 z-index: 9999，但它的父 .app 容器被设了 z-index: 10，而 Header 是 .header，直接挂在 body 下且 z-index: 100 —— 此时弹窗实际属于 .app 的层叠上下文内部，整体层级被压制。
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的「Layers」面板（Chrome）或「Rendering」>「Layer borders」辅助观察层叠上下文边界
- 避免在非必要层级（如最外层 wrapper）滥用
z-index，尤其不要给position: relative的布局容器设z-index - 全局可复用的层级变量建议集中定义，例如：
:root { --z-modal: 1000; --z-header: 100; --z-tooltip: 900; }，统一管理而非散落各处
z-index 能用 auto 吗？什么时候该用？
z-index: auto 是默认值，表示该元素不创建新的层叠上下文，且其堆叠层级由其在文档流中的位置和父上下文决定。它不是“无效”，而是“顺从”。
容易踩的坑：有人以为设 z-index: auto 就能“重置”层级，结果发现元素突然被盖住——其实是因为它退回到了文档流默认堆叠顺序（比如后出现的元素自然在前一个之上），而你忘了它已脱离普通流（比如用了 absolute）。
- 仅当明确需要元素**不创建新层叠上下文**且**接受父上下文默认排序**时才用
auto -
position: fixed元素即使z-index: auto，也会创建层叠上下文（这是规范行为），这点常被忽略 - 慎用
z-index: 0替代auto：前者强制创建层叠上下文，后者不创建——效果可能完全不同
移动端 iOS Safari 中 z-index 表现异常怎么办？
iOS Safari（尤其旧版本）对 transform、opacity、will-change 等属性敏感，哪怕只是 transform: translateZ(0)，也会隐式触发层叠上下文创建，导致 z-index 行为与桌面端不一致。
常见错误现象：下拉菜单在 iPhone 上被轮播图遮挡，但 Chrome 没问题；检查发现轮播容器有 transform: translateX(...)，无意中让它成了层叠上下文根节点。
- 避免对非必要元素添加
transform或opacity: 0.99这类“伪硬件加速”写法 - 真要启用 GPU 加速时，优先用
will-change: transform并配合z-index显式管理 - 在 iOS 上调试时，打开 Safari 开发者工具 → 「Elements」→ 右键元素 → 「Show layer borders」，直观查看哪些元素意外成了层叠上下文
