z-index仅对定位元素（position为relative/absolute/fixed/sticky）生效；未设position或父容器创建新层叠上下文时，z-index无效；需结合pointer-events、transform等综合排查。
z-index 只对定位元素生效
直接给 div 写 z-index: 999 却没效果？大概率是因为没设 position。z-index 不是“谁写谁上”，它只在已定位（position 值为 relative、absolute、fixed 或 sticky）的元素上起作用。
常见错误：
– 给普通流内 div 加 z-index，完全无效
– 用 position: static（默认值）还配 z-index，等于没写
实操建议：
• 先确认目标元素有 position: relative（最常用，不改变布局流）
• 若需脱离文档流，用 absolute 或 fixed，再配 z-index
• 避免滥用 position: absolute 布局整页，易破坏响应性
父容器 stacking context 会截断 z-index 比较范围
两个兄弟元素，一个 z-index: 100，另一个 z-index: 200，但后者还是被盖住？问题往往出在它们的父容器创建了独立的层叠上下文（stacking context），导致子元素的 z-index 只在父容器内部比大小，跨父级无法直接比较。
立即学习“前端免费学习笔记（深入）”；
触发 stacking context 的常见情况：
• 父元素有 position: relative + z-index（非 auto）
• 父元素有 opacity 小于 1
• 父元素有 transform（哪怕只是 transform: translateZ(0)）
• 父元素有 will-change: transform
排查技巧：
• 在浏览器开发者工具中，悬停查看元素的 “Computed” 面板，搜 z-index 和 stacking context
• 临时移除父级的 opacity 或 transform，看层级是否恢复
• 不要盲目堆高 z-index: 999999，先理清嵌套结构
z-index 数值本身没有“魔法值”，但存在隐式层级顺序
z-index: 999 不一定比 z-index: 100 “更上层”——如果它们不在同一个 stacking context 里，数值毫无可比性。真正决定最终绘制顺序的是浏览器构建的层叠上下文树和每个 context 内部的层叠等级。
同一 stacking context 中的元素按以下顺序从下到上渲染：
• z-index: auto 或未设置（归入“stack level 0”）
• z-index 为负数的元素（如 -1）
• z-index: 0
• z-index 为正数的元素（按数值升序）
实用建议：
• 同一模块内用小跨度数值（如 10、20、30），留出扩展余地
• 全局弹窗/遮罩层可用 z-index: 1000 起步，导航栏用 500，内容区用 1，形成清晰梯度
• 避免用 z-index: 2147483647 这类最大整数——既难维护，也掩盖了 stacking context 设计缺陷
移动端 touch 层级错乱常因 pointer-events 或 transform 干扰
H5 页面在 iOS 上点击区域失效、遮罩层点不透、按钮被盖住却看不见？除了 z-index，还要检查 pointer-events 和 transform 是否意外阻断了事件流。
典型现象：
• 弹窗显示正常，但点击空白处无法关闭（遮罩层 z-index 正确，但 pointer-events: none）
• 某个 transform: scale(0.99) 的容器内按钮无法点击
• iOS Safari 中 fixed 定位元素在滚动时闪动或层级异常
修复方向：
• 确保遮罩层有 pointer-events: auto（默认值），需要穿透时才设 none
• 移动端慎用 transform 触发硬件加速，尤其不要对交互密集的容器加无意义的 transform: translateZ(0)
• iOS 下 position: fixed 配合 z-index 有时需额外加 backface-visibility: hidden 或 -webkit-transform: translateZ(0) 来稳定层叠
层级控制不是调数字游戏，而是理解 stacking context 的生成与嵌套。最常被忽略的，是那个没写 position 却硬加 z-index 的 div，和那个悄悄用 opacity: 0.99 切断了整个子树层级关系的父容器。
