z-index本身不生效，必须搭配position（relative/absolute/fixed/sticky）才起作用；若写了z-index却无反应，90%因position仍为static或被父级层叠上下文隔离——需检查Computed中position值，并排查opacity
z-index 本身不生效，必须搭配 position 才能起作用；写上 z-index: 9999 却被盖住，90% 是因为漏了定位，或被父级层叠上下文锁死了。
为什么写了 z-index 却完全没反应？
最常见原因：目标元素的 position 还是默认的 static。CSS 规范明确要求，z-index 只对 position: relative、absolute、fixed 或 sticky 生效。
- 检查浏览器开发者工具的 Computed 样式，确认
position真的不是static - 别依赖父容器“带”子元素进定位上下文——子元素自己也得有
position声明 - Vue/React 组件中，内联样式或 CSS-in-JS 可能覆盖你写的
position，导致z-index形同虚设 - Flex/Grid 容器的直接子项虽支持
z-index，但一旦子项内部再用position: absolute，其后代就回归标准规则，不再继承父容器的层级控制
怎么避免被父级层叠上下文“关小黑屋”？
即使子元素 z-index: 9999，只要它某个祖先触发了新层叠上下文（stacking context），它就只能在那个“房间”里和兄弟比大小，出不去。
- 常见触发条件：
opacity小于 1、transform不为none（比如translateZ(0)）、filter、will-change、isolation: isolate - 典型现象：弹窗加了
transform: scale(1)做动画，结果被隔壁一个filter: blur(1px)的卡片压住 - 调试方法：Chrome DevTools → Layers 面板看上下文边界；或临时删掉可疑属性验证是否恢复
- 真需要动效又想保层级？把
transform或filter移到子元素上，而不是父容器
z-index 数值该设多少才靠谱？
数值大小不决定全局谁在上，只决定「在同一层叠上下文中」谁更靠前。跨上下文时，起决定作用的是父级的绘制顺序。
- 别用
z-index: 9999或2147483647—— 容易掩盖结构问题，旧版浏览器可能溢出 - 按功能分段预留空档：比如
--z-toast: 100、--z-dropdown: 200、--z-modal: 1000 - 负值可用，但会让元素沉到父容器背景色之下（如果父容器有背景，就看不见了）
- 用 CSS 自定义属性统一管理，比散落各处的魔数更可控、可维护
什么时候干脆绕开 z-index？
当多个组件动态插入、层级关系复杂，或反复调数字仍不可靠时，换思路往往更稳。
- 把 Toast、Tooltip、全屏遮罩等浮层类元素
appendChild到底部——天然脱离原有上下文，靠 DOM 顺序就能保证最上层 - 用
isolation: isolate主动创建堆叠上下文，比靠opacity或transform副作用更明确 - 某些场景下，
transform: translateZ(0)虽能触发硬件加速，但 iOS Safari 对它敏感，可能意外创建上下文，要小心
真正卡住人的从来不是 z-index 本身，而是它背后那套隐式、嵌套、浏览器不声张的层叠上下文规则。调数字前，先打开 Layers 面板看看“房间门”在哪。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
