z-index显示“not applicable”说明元素未参与层叠，主因是position为static；父级创建层叠上下文（如opacity
元素的z-index在Computed面板里显示为“not applicable”
这说明浏览器压根没把它当层叠参与者，最常见原因是position值仍是static——哪怕你写了z-index: 999，它也像没写一样。
实操建议：
- 打开Chrome DevTools → Elements → 选中目标元素 → «Computed» 面板搜
position，确认最终值不是static - 临时加一句
position: relative（不扰动布局），立刻验证z-index是否生效 - Vue/React里动态class切换后，容易被其他样式覆盖回
position: static，需检查最终computed值 - JS插入浮层（如toast）时，常漏掉
position声明，必须显式设position: fixed或position: absolute
父级元素被DevTools标为“Stacking Context: Yes”
只要某个祖先满足以下任一条件，它就创建了独立层叠上下文，“结界”一立，子元素的z-index只在它内部比大小，出不去。
实操建议：
- 在DevTools Elements面板中逐级点击父节点，右侧面板«Layout»标签页里看「Stacking Context」是否突然变成
Yes - 高危属性包括：
opacity小于1（哪怕opacity: 0.999）、transform不为none（比如transform: scale(1)或translateZ(0)）、filter不为none、will-change: transform、isolation: isolate - 临时注释掉父级的
transform或opacity，遮挡立刻消失——这就是实锤 - 特别注意
z-index: 0：它会强制创建新上下文，而z-index: auto（默认）不会；别误把z-index: 0当“安全兜底”
移动端fixed弹窗被body或html上的transform截断
iOS Safari对body和html极其敏感：html { transform: translateZ(0) }会让整个页面变成单一层叠上下文，再高的z-index也只能在它内部排第一。
实操建议：
- 打开移动端调试器（Chrome Remote Debugging 或 Safari Web Inspector），逐级点开
html→body→根容器，看«Computed»里是否有stacking context: yes - 优先删掉
body和html上所有transform、opacity、filter - 确保
min-height: 100vh存在，避免flex居中异常间接触发裁剪 - 轮播图、视差滚动等组件的wrapper若用了
transform，也会把整个子树锁死，别只盯着弹窗本身
用CSS自定义属性统一管理z-index区间
不同堆叠上下文之间，只比较“最顶层”的z-index；子层内部再大，也赢不过父层整体更小的数值。盲目堆z-index: 9999只会让后续嵌套被迫升级成99999，失控。
实操建议：
- 按模块划分基础区间：
--z-nav: 100、--z-modal-overlay: 1000、--z-modal-content: 1001 - 在CSS里写
z-index: var(--z-modal-content)，改一处全更新 - Tailwind用户注意：
zIndex必须在tailwind.config.js中以对象语法定义（如{ 'modal': '60' }），改完要重启dev server；z-[999]这种动态拼接在构建时不会被扫描 - 两个组件总打架，优先检查它们最近的共同祖先是否意外创建了层叠上下文，而不是调子元素数值
opacity: 0.99后面。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
