z-index用于控制定位元素在层叠上下文中的垂直堆叠顺序，其生效前提是元素position不为static，且层级比较仅限于同一层叠上下文中；创建层叠上下文的条件包括设置z-index、opacity
CSS中的
z-index属性，它的核心作用是控制同一层叠上下文（stacking context）内定位元素（positioned elements）的垂直堆叠顺序。简单来说，它决定了哪些元素会“浮”在上面，哪些会“沉”在下面。但要让它真正听话，理解其背后的层叠上下文机制是关键，否则你可能会发现，明明设置了很高的
z-index，元素却纹丝不动。
解决方案
要有效地利用
z-index，首先要明确它并非全局生效的魔法数字。它的作用范围严格限定在层叠上下文之内。一个元素只有在具备以下条件之一时，其
z-index属性才能发挥作用：
-
position
属性不为static
：这意味着元素必须是relative
、absolute
、fixed
或sticky
。这是z-index
生效的先决条件。 -
创建了新的层叠上下文：这是理解
z-index
行为的关键。当一个元素创建了新的层叠上下文时，它的所有子元素都会在这个新的上下文中进行堆叠，而这个上下文本身又会作为一个整体，在它的父级层叠上下文中进行堆叠。
如何创建层叠上下文？除了
position属性不为
static且设置了
z-index之外，还有很多CSS属性会隐式地创建层叠上下文，比如：
opacity
属性值小于1transform
属性值不为none
filter
属性值不为none
perspective
属性值不为none
will-change
属性值指定了任何会创建层叠上下文的属性（如opacity
,transform
等）flex
或grid
容器的子元素，如果设置了z-index
（即使position
是static
，但通常为了z-index
生效，它们也需要position
）mix-blend-mode
属性值不为normal
isolation
属性值为isolate
- 等等...
当一个元素创建了层叠上下文，它的
z-index值只与同级层叠上下文中的元素进行比较。它的子元素的
z-index值，无论多大，都无法跳出这个父级层叠上下文的限制，去影响外部元素的堆叠顺序。
立即学习“前端免费学习笔记（深入）”；
实际操作时，我会先确定需要调整层级的元素是否满足
position要求。然后，我会检查它们的父级元素，看是否存在隐式创建的层叠上下文，这往往是
z-index不按预期工作的原因。一旦理解了层叠上下文的边界，
z-index的调整就变得有章可循了。
为什么我的z-index设置了却没效果？
这大概是每个前端开发者都遇到过的“老大难”问题。在我多年的开发经验中，遇到
z-index失效的情况，通常有几个核心原因。
首先，也是最常见的，你可能忘记给元素设置position
属性了。记住，
z-index只对
position属性为
relative、
absolute、
fixed或
sticky的元素生效。如果你的元素
position是默认的
static，那么无论你给它设置多大的
z-index值，它都不会有任何层级上的变化。这就像你给一个普通人颁发飞行执照，他没飞机也飞不起来一个道理。
其次，层叠上下文的限制。这部分是真正让人头疼的地方。你可能有两个元素A和B，你希望A在B上面。你给A设置了
z-index: 100，给B设置了
z-index: 10。但如果A和B分别位于不同的层叠上下文里，比如A的父元素创建了一个层叠上下文，而B的父元素也创建了另一个层叠上下文，那么A和B的
z-index值就只在各自的上下文内有效。它们之间的堆叠顺序，将由它们各自的父级层叠上下文的
z-index（或创建方式）来决定。举个例子，如果A的父级上下文的
z-index是1，B的父级上下文的
z-index是2，那么无论A自身
z-index多高，它最终都会在B的下面。这种情况下，你需要调整的是父级层叠上下文的
z-index，而不是子元素。
此外，一些CSS属性的副作用也会创建新的层叠上下文，这往往是隐蔽的陷阱。比如，你可能无意中给一个父元素设置了
opacity: 0.9，或者
transform: scale(1)，甚至
filter: blur(1px)，这些都会让这个父元素成为一个新的层叠上下文。一旦它成为上下文，它的子元素的
z-index就只能在它内部玩，无法影响到外部的元素。我通常会使用浏览器的开发者工具，检查元素的
position属性和它所有父级的CSS属性，特别是那些可能创建层叠上下文的属性，这样能很快定位问题所在。
z-index负值有什么特殊用途？
z-index的负值，在我看来，是一种非常有趣且实用的特性，它允许我们创造出一些传统布局难以实现的效果。它的主要用途在于将元素放置在其父级元素的背景之下，但仍然在其父级元素的边框和内容之上。听起来有点绕，但想象一下，你可以让一个元素“沉”到父级元素的底层，却不被父级内容完全覆盖。
具体来说，当一个定位元素的
z-index被设置为负值时：
-
它会堆叠在父级元素的背景和边框之下。这意味着如果你有一个父元素，它有背景颜色或背景图片，并且有边框，那么负
z-index
的子元素会跑到这些东西的下面。 - 它会堆叠在父级元素的任何非定位子元素和文本内容之下。
这有什么用呢？
-
背景特效和视觉分层：你可以创建一个带有负
z-index
的伪元素或实际元素，作为父元素的一个“内嵌背景”或“底层装饰”。比如，一个浮动卡片下面的一层阴影，或者一个带有纹理的背景层，它需要位于卡片的主内容之下，但又不能完全脱离卡片。 -
交互式底层元素：设想一个场景，你希望在页面上放置一个半透明的覆盖层，当用户点击它时，下面的内容能做出反应。如果这个覆盖层使用正
z-index
，它会阻挡点击事件。但如果它是一个具有负z-index
的元素，并且其父元素没有遮挡它，它就可以作为一种独特的交互层。 -
复杂布局的视觉深度：在一些需要多层视觉深度的设计中，负
z-index
能帮助你将某些元素“推”到更深的层次，而无需改变它们的DOM结构。例如，一个视差滚动效果中，某些元素可能需要比其他元素“更远”。
使用负
z-index时，一定要注意它仍然受限于层叠上下文。如果父元素本身没有创建层叠上下文，或者它的
z-index值不够低，负
z-index的子元素可能仍然无法达到你想要的效果。调试时，我常常会调整父元素的
z-index，或者给父元素添加
position: relative，来确保负
z-index的子元素能按照预期工作。
如何避免z-index层级混乱和调试难题？
z-index层级混乱，是项目开发中非常常见的“坑”。它就像一个无形的手，悄悄地打乱你的布局，而且往往在你最意想不到的地方出现。为了避免这种混乱和调试的痛苦，我总结了一些个人经验和最佳实践。
首先，理解并管理层叠上下文是核心。不要把
z-index看作是全局的数字游戏。每次设置
z-index时，都要问自己：这个元素在哪个层叠上下文里？它的父级元素是否创建了新的层叠上下文？如果对层叠上下文的边界不清晰，很容易陷入
z-index大战，大家都在拼命地把数字往大里设，最终导致代码难以维护。我通常会在代码注释中明确指出某个元素创建了层叠上下文的原因，或者为什么它的
z-index需要设置成某个值。
其次，避免使用过大的z-index
值。我见过很多代码，为了确保元素能显示在最前面，直接给
z-index设置成
9999、
99999甚至更高。这种做法短期内可能解决问题，但长期来看，会为将来的维护埋下巨大隐患。当需要在此之上再添加一个元素时，你可能被迫使用
999999，这简直是噩梦。我的建议是，尽可能使用小而递增的
z-index值，比如
1, 2, 3...，或者
10, 20, 30...。这样，当需要插入新层级时，你有足够的空间。对于一些通用的、需要高层级的组件（如模态框、下拉菜单），可以约定一个相对较高的基础值（比如
1000），然后在此基础上进行增减。
再者，利用CSS自定义属性（CSS Variables）来管理z-index
。对于一些通用的层级，比如导航栏、模态框、工具提示等，我倾向于定义CSS变量，例如
--z-index-nav: 100;、
--z-index-modal: 1000;。这样，你可以在一个地方管理所有关键的
z-index值，提高了可维护性。当需要调整某个全局层级时，只需修改变量值即可。
最后，善用浏览器开发者工具进行调试。这是我排查
z-index问题的利器。在Chrome或Firefox的开发者工具中，你可以选中一个元素，查看它的
position和
z-index属性。更重要的是，你可以查看它的所有祖先元素，并检查它们是否创建了层叠上下文（通过查看
opacity、
transform等属性）。有些浏览器插件甚至能可视化层叠上下文，这对于理解复杂布局非常有帮助。如果一个元素没有按照预期堆叠，我通常会从它的父元素开始向上追溯，直到找到创建层叠上下文的那个“罪魁祸首”。
总的来说，处理
z-index就像玩乐高积木，你得知道哪些积木能堆叠，哪些不能，以及它们堆叠的规则。而不是盲目地把所有积木都往高处堆。
