z-index:999无效主因是元素未处于同一层叠上下文：必须先设position非static，再确认父元素未因opacity
z-index:999 无效？先确认是否在同一个层叠上下文里
直接给元素设 z-index: 999 却被挡住，大概率不是值不够大，而是它和遮挡它的元素根本不在同一个“Z轴空间”里。CSS 的 z-index 只在**同一层叠上下文（stacking context）内**生效。一旦父容器自己创建了新的层叠上下文（比如设置了 z-index、opacity、transform 等），子元素的 z-index 就只在这个小空间里比大小，再高也跨不出去。
- 常见触发新层叠上下文的父级样式：
position: relative+z-index: 0（或任意非auto值）、opacity: 0.99、transform: translateZ(0)、will-change: transform - 浏览器 DevTools 中，选中元素后在 “Computed” 面板里搜
stacking context，能快速判断它是否是某个上下文的根 - 如果遮挡者是父元素（比如弹窗内部的按钮被弹窗背景盖住），检查父元素是否意外触发了层叠上下文 —— 很多时候只是加了个
z-index: 0或opacity: 0.999就够了
同级元素没设置 z-index，谁在上面？看 HTML 顺序和默认堆叠规则
两个 position: relative 或 position: absolute 的同级元素，都没写 z-index，那谁压谁？答案是：**后写的那个在上面** —— 这是 CSS 默认的“后来者居上”规则。但要注意，这个规则只在它们属于同一个层叠上下文、且 z-index 都为 auto 时才起作用。
-
z-index: auto（未显式声明）的定位元素，默认不参与层级比较，按源码顺序堆叠 -
z-index: 0和z-index: auto不等价：前者会创建新层叠上下文，后者不会 - 如果一个同级元素写了
z-index: 1，另一个没写，那写了的那个一定在上面；但如果两者都写了，数值大的胜出
检查父容器的 position 和 z-index 是否“锁死”了子元素层级
子元素设了 z-index: 999，父容器却设了 z-index: 1，结果子元素还是被兄弟容器（z-index: 100）挡住 —— 这不是 bug，是预期行为。因为子元素的 z-index 是相对于父容器的层叠上下文计算的，它最多只能“撑满”父容器所占的 Z 层高度，无法突破父容器在整个页面中的层级位置。
- 父容器
z-index: 1→ 它在页面中 Z 层排第 1 位；子元素z-index: 999→ 它在父容器内部 Z 层排第 999 位，但对外仍属于“第 1 层” - 要让子元素真正“浮出来”，必须提升它的父容器层级，或者把该子元素移出当前父容器（比如用
portal或动态挂到body下） - 特别注意：
position: fixed元素默认以视口为包含块，但它依然受其最近层叠上下文约束（比如被 opacity
为什么 Chrome DevTools 显示 z-index 生效，但视觉上还是被盖？
DevTools 的 Styles 面板显示 z-index: 999 已应用，不代表它真的“赢了”。可能原因包括：
- 目标元素实际被更外层的层叠上下文包裹（比如整个导航栏用了
transform，导致内部所有z-index失效） - 遮挡者是
<select></select>、<iframe></iframe>或某些旧版<object></object>—— 这些是窗口控件（windowed plugin），会无视z-index，永远浮在最顶层 - CSS 选择器优先级导致样式被覆盖（比如另一个更具体的规则把
z-index改成了1，而你只看了第一个匹配项） - 元素本身透明度为 0 或
visibility: hidden，看起来像被挡，其实是不可见
真正卡点往往不在数字大小，而在层叠上下文的嵌套边界 —— 它看不见、摸不着，但决定一切。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
