层叠样式表中z-index属性的使用频率很高，但真正理解它运行机制的人并不多。很多情况下，开发者对z-index的理解停留在“数值越大，元素显示越靠前”的层面，一旦碰到异常表现，往往直接把数值调到9999或者更大，结果问题依旧存在。比如一个position:absolute的弹窗无论如何都盖不住底部导航条，或者在表格单元格里设置z-index完全没有反应。出现这类状况时，需要回到CSS规范本身，看看z-index的生效条件、层叠上下文的建立方式，以及不同定位元素之间的层级比较规则。
z-index的基础生效条件：为什么有时候写了等于没写
z-index并不是作用于任意元素的属性。规范中明确规定，z-index只对定位元素（position值为relative、absolute、fixed或sticky）以及flex容器的子项生效。如果一个元素是静态定位（position默认的static值），给它设置z-index属性时，浏览器会直接忽略这个值，元素始终按照DOM文档流中的自然顺序排列。这就是为什么在很多场景下写了z-index却丝毫不起作用的最常见原因。
这里有一个容易混淆的点：很多人以为设置了float也可以配合z-index使用。但float元素的定位方式仍然属于静态定位的范畴，它虽然产生了浮动效果，却不属于定位元素，因此z-index对它无效。float元素之间的重叠顺序由文档流顺序决定，后面的浮动元素会盖住前面的浮动元素。如果确实需要控制两个浮动元素的层级，正确的做法是给它们加上position:relative，再设置z-index。
/* 错误示例：z-index对静态定位元素无效 */
.box-a {
z-index: 10;
}
/* 正确示例：必须配合定位属性 */
.box-a {
position: relative;
z-index: 10;
}
/* flex子项可以不用定位属性 */
.flex-container {
display: flex;
}
.flex-container .item-a {
z-index: 5;
}
在开发调试时，遇到z-index无效的情况，第一步要检查的是目标元素的position是否已经设置。检查顺序也很简单：打开浏览器开发者工具，选中元素，查看Computed面板中position的值，如果是static，那么z-index被禁用就是意料之中的结果。这一步排查往往能解决大部分“失灵”的问题。
层叠上下文：z-index真正的话语权边界
当一个元素既设置了定位又设置了z-index后，它会创建一个叫层叠上下文（stacking context）的独立环境。页面根元素html本身就是最外层的层叠上下文，所有直接或间接的z-index比较都发生在各自的上下文内部。理解这一点非常重要：z-index的数值比较不是全局性的，而是受限的，只有处于同一个层叠上下文中的元素之间才可以直接比较数值大小。
举个例子，一个父元素
除了显式的z-index之外，很多CSS属性也会意外地创建层叠上下文，这是排查层级问题时的另一大隐藏雷区。常见的情况包括：transform属性值不为none、opacity小于1、filter不为none、will-change指定了这些属性、混合模式mix-blend-mode不为normal，以及position:fixed本身（大多数现代浏览器中fixed元素会创建上下文）。一个元素只要命中了上述任何一个条件，就会形成一道隐形的“层级围墙”，内部的z-index再高，也只能在围墙内部发挥作用。
/* 这些写法会意外创建层叠上下文 */
.card {
transform: translateY(20px);
}
.mask {
opacity: 0.8;
}
.blur-box {
filter: blur(4px);
}
.animatable {
will-change: transform;
}
排查这类问题时，除了看元素本身的z-index，还需要沿着DOM树向上检查每一层祖先元素是否带有这些属性。很多时候一个平平无奇的父容器使用了半透明背景（opacity:0.9），就会导致所有子元素的层级展示异常。找到这条链路上的“罪魁祸首”，将相关属性做最小化处理，或者将不必要的transform和opacity移到不影响层级的伪元素上，就能恢复预期的层叠效果。
常用修复方案对比：调数值、换思路、加隔离
面对元素重叠层级错乱的问题，处理思路主要有三条路径：其一是直接调整z-index数值，适合简单场景；其二是从HTML结构入手，通过改变元素在文档流中的先后顺序来控制层叠效果；其三是利用isolation属性为特定容器建立独立的层叠上下文，阻断层级穿透。三条路径适用场景不同，修复成本和风险也各不相同。
简单调整z-index数值是最直接的方法，但局限性也很明显：当一个层叠上下文内部涉及多个弹窗、下拉菜单、提示浮层时，数值管理和记忆成本会变得很高。曾经有团队为了区分不同浮层的层级，约定弹窗用1000、下拉菜单用500、提示用100，但遇到弹窗内部再有浮层时会直接面临数值分配冲突，后期维护非常痛苦。与此同时，数值越大的元素并不代表着全局层级越高，如果两个元素分属不同的层叠上下文，数值比较就失去了意义。
调整DOM结构是另一种低成本方案。因为在不涉及层叠上下文的前提下，文档流中靠后的元素会自然覆盖靠前的元素。把需要展示在顶层的浮层节点移动到body末尾，或者移动到目标容器的内部末尾，往往能避开复杂度较高的上下文交错。这种方案不涉及任何层叠属性变化，修改成本低，也更容易被同事理解。但缺点是结构上可能与业务逻辑绑定的位置不符，需要额外做注释说明。
<!-- 调整结构：把浮层放到容器末尾，利用文档流顺序 --> <div class="container"> <div class="header">标题区域</div> <div class="content">正文区域</div> <!-- 浮层放到最后，自然层级最高 --> <div class="float-button">悬浮按钮</div> </div>
isolation属性是解决层叠上下文穿透最优雅的方案之一。它允许开发者在不改变元素定位方式的情况下，为指定元素强制建立一个新的层叠上下文。例如，页面中存在一个全局的侧边导航栏，使用了transform动画导致悬浮按钮被盖住，这时候在悬浮按钮的外层容器上添加isolation:isolate，这个容器连同它内部的所有子元素就会形成一个相对独立的层级整体，侧边导航栏再高的z-index也无法直接穿透到它内部。使用isolation的代码干净，语义清晰，维护难度低，非常适合作为层级隔离的默认选项。
.floating-layer {
position: fixed;
bottom: 20px;
right: 20px;
isolation: isolate;
z-index: 10;
}
实战案例：一个自定义下拉菜单的层级修复
下面用一个具体的页面片段来综合展示排查思路。场景是一个后台管理页面，顶部有一排导航按钮，鼠标悬停时展开下拉菜单。页面上同时还有一个带定位的“回到顶部”按钮。出现的问题是下拉菜单展开后，hover到底部的“回到顶部”按钮区域时，“回到顶部”按钮会被下拉菜单盖住一部分。尽管给下拉菜单设置了z-index:100，似乎并没有解决问题，仔细观察发现始终还是“回到顶部”按钮显示在上面。
初步排查下来，“回到顶部”按钮并没有设置极高的z-index，下拉菜单的z-index:100按理说应该生效。进一步检查发现，“回到顶部”按钮所在的侧边容器设置了opacity:0.6的透明效果。这个opacity小于1的写法让侧边容器成为新的层叠上下文，容器内部的按钮即便没有主动设置z-index，也跟随容器整体参与了层叠比较。而下拉菜单虽然z-index较高，但由于它属于顶部的导航条上下文，两个上下文之间的比较结果取决于导航条容器和侧边容器之间的z-index，而不是内部元素的z-index。最终结果是侧边容器因为自然靠后，压在了导航条上方，于是下拉菜单就被盖住了。这个现象相当有迷惑性。
<div class="page">
<nav class="top-nav">
<ul class="menu-list">
<li class="menu-item">
菜单选项
<div class="dropdown">下拉内容</div>
</li>
</ul>
</nav>
<aside class="sidebar">
<div class="back-top">回到顶部</div>
</aside>
</div>
.sidebar {
position: fixed;
right: 10px;
bottom: 10px;
/* 透明度导致的层叠上下文问题 */
opacity: 0.6;
}
.back-top {
position: relative;
z-index: 1;
}
.top-nav {
position: sticky;
top: 0;
z-index: 50;
}
.dropdown {
position: absolute;
z-index: 100;
}
修复方案是从根源上移除侧边容器的opacity属性，改用rgba或者其他不影响层叠上下文的方式来实现透明效果。例如将容器整体的透明改为背景色使用rgba值，或者将opacity转移到不影响定位子元素的伪元素上。修改之后，侧边容器不再创建新的上下文档，下拉菜单的z-index:100就能和页面顶部导航条保持一致，下拉菜单正常显示在按钮上方。
.sidebar {
position: fixed;
right: 10px;
bottom: 10px;
/* 修复：避免创建多余层叠上下文 */
background: rgba(0, 0, 0, 0.6);
}
这个案例说明了一个核心原则：修复层叠问题要顺着层叠上下文的链条去找源头，而不是盲目地给目标元素加z-index。开发者工具中的层叠面板（Layers）对于排查这类问题非常高效，它可以直观地展示每个层叠上下文的嵌套关系和实际顺序。熟练使用这些工具能够大幅提高定位问题的速度。
z-index使用规范建议：让层叠关系变得可维护
当项目规模增长到一定阶段，无节制的z-index赋值会带来很多隐患。推荐的做法是在设计组件库或全局样式时，定义一套可见的层叠变量体系。例如弹窗层1000、侧边栏层800、下拉菜单层600、全局浮动按钮层400，并在注释中添加说明。团队成员如果需要增加新的浮层，按照既有体系选择最近的档位，而不是任性地写上9999。这种约定配合CSS自定义属性实现，修改成本极低，也避免了数值满天飞的问题。
:root {
--layer-dropdown: 600;
--layer-sidebar: 800;
--layer-modal: 1000;
--layer-popover: 1200;
}
.modal {
z-index: var(--layer-modal);
}
.popover {
z-index: var(--layer-popover);
}
另外要强调的是，z-index属于表现层属性，业务代码中如果有根据业务状态动态调整层级的场景，建议通过切换类名来修改，而不是内联样式直接处理。这样在排查问题时可以一目了然地看到样式来源，也不会因为内联样式的高优先级而覆盖掉预期的设计规范。结构性调整和isolation隔离作为辅助手段，同样应当记录在样式注释中，方便后续维护者理解设计意图。
处理好多重定位元素的重叠问题，关键在于理解层叠上下文的边界，清楚每一个元素究竟在哪个上下文中参与计算。掌握了这一层原理，处理层叠冲突时就不再是碰运气式的不断调整数值，而是可以在短时间内定位到真正的问题节点，并选择合适的策略加以解决。