z-index失效主因是元素未定位或被父级层叠上下文隔离；需确保position非static，并排查opacity
绝对定位元素不按预期堆叠，基本可以断定是 z-index 没生效，而不是数值设小了——真正卡住它的，往往是某个父容器悄悄创建了独立的层叠上下文。
为什么 z-index 设了却没用？
根本原因不是值不够大，而是目标元素没进入可比较的层叠层级。只有同时满足两个条件，z-index 才真正起作用：元素自身 position 不为 static（比如设了 absolute），且它或其任意祖先触发了层叠上下文。
-
opacity: 0.99、transform: translateY(0)、filter: blur(1px)、will-change: transform都会意外创建新层叠上下文 - 一旦父容器创建了上下文，子元素的
z-index: 9999也只在该容器内部有效，无法盖过兄弟容器里的z-index: 1元素 - 调试时可在开发者工具中临时加
outline: 1px solid red，快速识别哪些父级“关住了”你的层级
父容器必须设 position: relative 吗？
不是“必须”，而是“最安全”。position: absolute 的定位基准是最近的已定位祖先（relative / absolute / fixed / sticky）。如果漏掉这层，元素会一路往上找，最终相对于 body 定位，导致偏移失控。
- 设
position: relative是显式声明“这里就是我的定位锚点”，不改变布局，只提供参照 - 如果父容器已有
transform或opacity，它其实已经“已定位”，但同时也创建了新层叠上下文——这时relative反而可能帮你显式建立一个干净的上下文 - 不要给父容器设
z-index: auto或不设，它等价于0且不创建新上下文；要就设z-index: 0显式声明
多个图层共用同一区域时怎么避免遮挡交互？
用 position: absolute 叠在一起的图层，默认会拦截鼠标事件。如果你只是想视觉叠加，又不想影响底层点击，就得主动放行。
- 对非交互图层（比如装饰性云朵、模糊背景）加
pointer-events: none - 如果某层需要响应点击，但又不能挡住下层，可搭配
pointer-events: auto和z-index精细控制 - 移动端注意：
will-change: transform可能触发额外合成层，增加内存开销，仅在真实性能瓶颈处启用 - 纯静态多层背景优先用
background-image: url(a.jpg), url(b.png)，比 DOM 层叠更轻量；只有需要独立动画、缩放或事件响应时，才上div + absolute
z-index 数值到底该怎么设才不翻车？
数值本身没有意义，关键看它在哪个层叠上下文里跟谁比。不同上下文之间，只比“顶层”的 z-index，子层再高也出不来。
- 避免硬写
9999；按功能分段：弹窗100–199，提示气泡200–299，遮罩层300 - 用 CSS 自定义属性统一管理，比如
--z-modal: 100;，然后z-index: var(--z-modal); - iOS Safari 对
z-index有隐式截断（约 838 万），超高值反而失效；fixed+transform+z-index组合在 iOS 15+ 更容易踩坑
最常被忽略的是：你改了一个 z-index，可能要同步检查三层父级是否都意外带了 opacity 或 filter——它们不会报错，但会让整个层级体系静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
