z-index失效根本不是数值问题，而是元素未进入同一层叠上下文；需确保目标元素已定位（position非static），并排查祖先元素是否因opacity<1、transform非none、filter、will-change、isolation: isolate或position+z-index组合触发新层叠上下文，导致子元素z-index被限制在局部范围。
z-index 为什么设了也不生效
根本不是数值不够大，而是元素压根没进同一个比较场。z-index 只在同层叠上下文中起作用，一旦父级触发了新上下文，子元素的 z-index 就被锁死在局部范围里。
常见触发父级创建新层叠上下文的属性：opacity 小于 1（哪怕 opacity: 0.99）、transform 非 none（包括 translateZ(0)）、filter、will-change、isolation: isolate，还有 position + z-index 组合（哪怕 z-index: 0）。
排查方法：
- 用 Chrome DevTools 选中目标元素 → 「Computed」面板搜
stacking context，看是否标为 “Yes” - 逐级向上检查父元素的
opacity、transform、filter等值 - 临时给可疑父容器加
opacity: 1 !important或transform: none !important，观察层级是否恢复
absolute 元素突然飞到左上角
这不是 top 和 left 写错了，而是它没找到定位参考系。position: absolute 会向上查找**最近的非 static 定位祖先**作为包含块；如果全都是默认 position: static，就直接相对于 viewport 定位。
立即学习“前端免费学习笔记（深入）”；
快速验证：
- DevTools 中选中该元素 → 「Computed」面板找
Containing block字段，看它实际绑定的是哪个节点 - 在 Elements 面板里从父节点开始逐级点开，确认是否有节点设置了
position: relative、absolute或fixed - 若预期父容器没设定位，就给它加
position: relative（无需偏移值），让它成为合法锚点
移动端 Safari 中 z-index + transform 组合失效
iOS Safari 对 transform 和 z-index 的配合极其敏感：只要父容器用了 transform（哪怕只是 translateZ(0)），又没显式声明 z-index，其子元素即使设了 z-index，也可能被错误渲染。
稳妥解法：
- 在触发
transform的父容器上，**同时加position: relative和z-index: 0** - 避免只靠
transform: translateZ(0)强制硬件加速却不设z-index - 测试必须用真机，模拟器常无法复现该问题
如何让 z-index 管理不翻车
硬写 z-index: 9999 是在给未来埋雷。真正可维护的方式是语义化分层 + CSS 自定义属性统一管理。
推荐分层区间（留足余量）：
-
--z-base: -10 ~ 0（遮罩背景、禁用蒙层） -
--z-content: 10 ~ 99（卡片、表单、文章区域） -
--z-nav: 100 ~ 199（导航栏、侧边栏） -
--z-overlay: 1000 ~ 1999（modal、toast、dropdown）
关键约束：
- 所有浮层类统一用
class="z-modal"这类语义名，不要散落在各处写z-index - 在
:root中定义变量，组件内用z-index: var(--z-modal) - 避免中间容器意外创建层叠上下文——必要时给它加
z-index: auto或移除transform/opacity
最易被忽略的一点：层叠上下文是“传染性”的，一个父级触发，整棵子树都进隔离区。调试时别只盯着出问题的元素，要往上看三层。
