z-index 调到很大还是被盖住，2026年继续往上加有用吗？

CSS 里 z-index 调到很大还是被盖住，多数不是数值不够，而是两个元素没在同一个层叠上下文里比较。2026 年交付里更稳的顺序是：先找最近的共同层叠上下文，再判断是调数值、去掉触发属性，还是把元素挪层；直接加零往往只在当前页面有效。

一、z-index 只在同一个层叠上下文里比大小

层叠上下文可以理解成一个独立的小世界：内部元素按规则排序，世界之间的顺序由外层决定，内部元素无论 z-index 多大，都顶不出这个世界。所以判断遮挡永远是两步——先看两个元素在不在同一个层叠上下文，再看谁的数值更大；顺序反过来，就会一直在试数值。

一个常见误解是把 z-index 当成全局优先级数字。实际上有两种情况它并不参与比较：一是元素 position 为 static、且不是 flex 或 grid 容器的直接子项时，写了也不生效；二是父级在开发者毫无察觉的情况下新建了层叠上下文，把子元素整体降级到了另一层，此时父级里所有子元素的数值都只在自己那层有效。

• 定位元素：position 为 relative、absolute、fixed、sticky，且 z-index 不为 auto。
• 变换与透明：transform、scale、rotate 等值不为 none；opacity 小于 1；filter 或 backdrop-filter 不为 none。
• 性能与隔离：will-change 指定了 transform、opacity 等属性；isolation 为 isolate；contain 为 paint 或 layout。
• 布局容器子项：flex 或 grid 容器的直接子项，z-index 不为 auto 时同样会新建。

这份清单不用背。排查时打开开发者工具，逐个查看被盖元素的祖先 computed 样式更快；具体触发条件可按官方文档或 MDN 核对，不同浏览器在细节上偶有差异，交付前建议在目标浏览器里实测一遍。

二、三层定位法：先确认层，再动数值

拆成三步而不是一步，是因为每一步的结论完全不同：第一步只确认现象，第二步确认层级关系，第三步才动代码。跳过前两步直接加数值，最常见的结果是本地好了、换个页面又坏了。

1. 确认遮挡关系：选中被盖住的元素，看它自身的 position 与 z-index，再往上逐级看祖先，找出第一个新建了层叠上下文的祖先。
2. 找共同比较层：从两个元素向上找最近的公共祖先；如果两者之间任何一方新建过层叠上下文，它们就不在同一层，此时比数值没有意义。
3. 同层排顺序并选择修法：同一层里，定位元素 z-index 大者在上，数值相等时靠后出现在 DOM 中的在上；能去掉多余的层叠上下文就去掉，去不掉就把元素挪到同一层，最后才考虑在共同层里统一调整数值。

第二步容易被跳过，却决定后面改得对不对。判断标准很直接：如果你说不出这两个元素共同的层叠上下文是谁，那现在改的任何数值都只是碰运气。合格的修法是改完之后，能在开发者工具里指出两者确实处在同一层，并且换一个页面复用同一组件时不再出问题。

顺带说一个反例：有人用 position: relative 配合 z-index: -1 把装饰层压到内容下面，结果整块内容在部分浏览器里变得点不到、也选不中文字。装饰层更稳妥的做法是用一个独立的背景层容器，而不是靠负值往下压。

三、交付现场：老项目里 z-index 越加越大，返工是迟早的

在中后台类项目里常见这样一组约束：页面用第三方组件库，一个页面同时存在下拉筛选、气泡提示、表格固定列和右侧抽屉，排期只给两三天。做法是先把浮层按用途分档、写进项目说明，遇到遮挡先判断属于哪一档，再决定加不加零。代价是第一次联调仍有两处遮挡返工——在内层补了 z-index 之后，另一个页面的下拉框被顶到了弹窗下面，多花半天做回归。经验区间上，浮层类型超过五六种、跨页面复用明显的项目，才值得维护分档表；只有一两个浮层的页面，维护成本通常换不回收益。

四、方案对比：就地加数值、拆层、还是统一层级规范

三种做法没有绝对好坏，取决于项目要活多久、浮层密度有多高。按 2026 年常见做法，可以用下面这个维度对一下：

• 方案 A：就地加 z-index 数值。成本很低，常见是几分钟；适合单页宣传站、浮层不超过两三个的页面。副作用是数值通胀，下一个人只能加得更大。
• 方案 B：把浮层挪层，例如挂到 body 或用 portal。成本中等，含定位处理与回归，经验区间半天到两天；适合组件库弹窗被局部容器裁剪、被父级层叠上下文压住的项目。
• 方案 C：定一份层级分档规范。前期成本常见 0.5 到 2 天，收益体现在后续每次新增浮层；适合多人协作、浮层类型多的产品。

分档不用复杂，按经验区间大致是：内容与卡片 0 到 10，悬浮操作条 100 到 200，下拉与气泡 300 到 500，弹窗与抽屉 800 到 1000，全局提示与加载遮罩 2000 以上。这只是常见区间，不是硬标准；团队内部口径统一，比数值大小本身更重要。

五、适用场景与边界

值得认真处理层级的，通常是浮层多、组件复用多、还混用了第三方 UI 库的项目。这类项目里遮挡问题会反复出现在不同页面，一次性定好分档比每次救火便宜。判断是否合格的标准也简单：新增一个浮层时，开发者能不能在不看别人代码的情况下确定它该用哪一档。

边界也要写清楚：如果页面只有一两个浮层、没有组件库混用、也没有跨页面复用，直接把 z-index 写在对应样式里通常就够用，专门抽一套层级规范反而属于过度设计。反过来，如果项目里已经出现大家都在往上加零的现象，那问题就不只是某一处样式，而是缺一份约定。

常见问题

z-index 是不是只有定位元素才生效？

多数场景需要 position 为 relative、absolute、fixed、sticky 之一；不过 flex 或 grid 容器的直接子项即使没有定位，z-index 同样会参与排序。

父级加了 transform，子元素 z-index 就不好使了，怎么办？

父级的 transform 新建了层叠上下文，子元素被锁在该层内。要么去掉这个 transform 或换一种实现方式，要么把子元素挪到与遮挡元素同一层。

两个元素 z-index 一样大，谁在上面？

同一层叠上下文内数值相等时，靠后出现在 DOM 中的元素在上。如果一个是定位元素一个不是，先按层叠顺序规则判断，不要只比数值。

弹窗被别的组件盖住，是不是一定要用 portal？

不一定。先确认两者是否同层：如果只是数值顺序问题，同层调整即可；只有弹窗被局部容器裁剪或被父级层叠上下文压住时，挪层才更省事。

下次再遇到元素被盖住，先别急着改数值：打开开发者工具确认祖先里有没有新建层叠上下文，再看两者是否同层，最后决定调数值还是挪层。项目允许的话，顺手把层级分档写进样式说明，能省掉后面很多次来回改样式与回归的时间。