z-index仅对position为relative、absolute、fixed或sticky的元素生效；静态定位下设置无效，且受层叠上下文限制，需避免意外创建上下文并分层管理数值。
z-index 只对定位元素生效
很多人给元素设了 z-index 却没效果，根本原因是该元素没有启用定位上下文。CSS 中 z-index 仅在 position 值为 relative、absolute、fixed 或 sticky 时才起作用。静态定位（position: static，即默认值）下设置 z-index 完全被忽略。
常见错误现象：div 层叠顺序没变，检查 computed styles 发现 z-index 显示为 auto —— 这说明它没被当作定位元素参与层叠计算。
- 必须显式写
position: relative（哪怕不偏移）才能激活z-index -
position: absolute和fixed天然满足条件，但要注意它们脱离文档流后可能影响布局 -
position: sticky在滚动触发后才进入定位状态，此时z-index才开始生效
层叠上下文（stacking context）会截断 z-index 作用范围
z-index 不是全局排序，而是相对于最近的层叠上下文。一旦父容器创建了新的层叠上下文（比如设置了 opacity: 0.99、transform: translateZ(0)、filter: blur(1px) 或非 auto 的 z-index），其子元素的 z-index 就只在这个“小世界”里比大小，无法越过父级和外部兄弟元素竞争。
典型陷阱：弹窗组件加了 z-index: 9999，但被一个半透明遮罩层盖住——很可能因为遮罩层父容器有 opacity: 0.8，提前建立了层叠上下文，导致弹窗再高也出不去。
立即学习“前端免费学习笔记（深入）”；
- 检查是否意外触发了层叠上下文：用浏览器开发者工具查看 “Computed” 面板里的
stacking context提示 - 避免无意义的
transform或opacity，尤其不要对布局容器滥用transform: translateZ(0)强制硬件加速 - 若需跨上下文控制层级，把需要突出的元素提到更高层级的 DOM 位置（比如挂到
body下），或统一剥离干扰属性
position 值决定定位基准和文档流行为
position 类型直接决定元素如何“入场”，进而影响它能否被 z-index 管理以及怎么跟其他元素互动：
-
position: relative：原地定位，保留占位；适合微调+叠加，如按钮上的角标、输入框的图标 -
position: absolute：脱离文档流，相对于最近的已定位祖先（或初始包含块）定位；常用于下拉菜单、气泡提示 -
position: fixed：相对于视口定位，滚动不跟随；适合导航栏、返回顶部按钮，注意它天然创建层叠上下文 -
position: sticky：条件性定位，滚动到临界点才“吸顶/吸底”；它不会创建新层叠上下文，但z-index生效时机取决于是否已触发定位
性能提示：absolute 和 fixed 元素频繁动画时，建议搭配 will-change: transform 或用 transform 替代 top/left，避免重排。
z-index 数值比较规则与常见误区
z-index 比较不是看绝对大小，而是按层叠上下文树逐级解析。两个同级元素，数值大的在上；但如果一个是另一个的后代，那祖先的层叠等级优先于后代的 z-index 数值。
错误做法：给所有组件都设超大值（z-index: 999999），结果某天引入第三方 UI 库，它的弹窗用了 z-index: 1000000，立刻被压住。
- 推荐分层管理：
z-index值按用途分段，例如：10（背景）、100（主内容）、1000（弹窗）、10000（全屏加载遮罩） - 避免使用
z-index: auto和z-index: 0混用：前者不参与层叠排序，后者会创建新层叠上下文，行为完全不同 - IE6–7 不支持
z-index在非定位元素上，且存在“父级z-index覆盖子级”的 bug，现代项目可忽略，但维护老系统需留意
真正难的不是写对 z-index，而是理清 DOM 结构里到底嵌套了几层层叠上下文——这往往比代码本身更耗调试时间。
