HTML怎么设置z-index层级_html z-index层叠顺序设置方法【基础】
先记住一个核心原则：z-index 只对已定位元素生效，没设 position（且值不为 static）的元素加 z-index 完全无效。 这是很多层级问题的根源。
为什么写了 z-index 却没效果？
最常见的原因其实很简单：元素没有触发定位上下文。在CSS的世界里，只有当一个元素的 position 属性值被设置为 relative、absolute、fixed 或 sticky 时，z-index 这个属性才会被浏览器“认账”。如果元素是默认的 position: static，或者干脆没写 position，那么无论你给 z-index 赋多大的值，都只是白费功夫。
开发中容易踩的坑，通常有这么几种：
- 父容器已经用了
position: relative来创建定位上下文，但子元素只写了z-index: 999，却漏掉了子元素自己的position声明（比如absolute）。 - 在使用 Flex 或 Grid 这类现代布局时，误以为子项会自动获得“可叠放”的能力，实际上，它们仍然需要显式地加上
position属性，才能让z-index生效。 - 在某些框架（如 Vue/React 组件）中，内联样式或组件库的样式可能会覆盖你写的
position规则，导致z-index失效。
z-index 数值怎么选才靠谱？
z-index 支持正数、负数和 0，但千万别陷入“数字越大越保险”的误区。在实际项目中，更靠谱的做法是根据层级意图进行分段预留，这样代码既清晰又好维护：
立即学习“前端免费学习笔记（深入）”；
- 基础 UI 层（如背景、遮罩）：建议使用
-1到9这个区间。 - 内容主体层（卡片、表单等常规内容）：可以放在
10到99这个范围。 - 浮层类（弹窗、下拉菜单、Tooltip提示）：这是最常用的浮动元素层，数值建议设定在
100到999。 - 全局强提示（如 Toast、全屏 Loading）：需要确保在最顶层，可以使用
1000+，但应避免硬编码诸如999999这样的极端数值。
虽然 z-index 的数值理论上没有上限，但过大的数字（比如 2147483647）可能在旧版浏览器中溢出，或者给后续的调试和代码维护带来不必要的困扰。
多个 z-index 元素重叠时谁在上面？
表面上看，规则似乎是“数值大者胜出”，但真实的底层逻辑依赖于一个更重要的概念——堆叠上下文（stacking context）。这里有几点关键：
- 每个设置了
position且带有z-index值（包括0）的元素，都可能创建一个新的、局部的堆叠上下文。 - 子元素的
z-index只会在它所属的这个堆叠上下文内部进行比较，它无法跨越上下文去和父级的兄弟元素一较高下。 - 如果两个元素分别属于不同的堆叠上下文（比如它们分别位于两个不同的
position: relative父容器内），那么它们各自的z-index数值之间是没有任何可比性的，谁在上层完全由各自父容器的堆叠顺序决定。 - 没有设置
z-index的定位元素，默认处于该上下文的z-index: auto层，其渲染顺序通常按照它们在HTML中间出现的先后顺序排列。
可以做个简单验证：给一个父容器加上 z-index: 1 和 position: relative，然后在其内部为两个子元素分别设置 z-index: 99 和 z-index: 1，它们的相对顺序是有效的。但如果把这两个子元素分别放到两个不同的父容器下，即使它们的 z-index 数值相同，谁在上面就完全由各自父容器的 z-index 决定了。
移动端或复杂布局下要注意什么？
在某些特定场景下，z-index 的表现可能会有些反直觉：
- 在 iOS Safari 中，使用
transform: translateZ(0)或will-change: transform这类属性可能会意外地创建新的堆叠上下文，导致预期之外的元素“浮”到最上面。 - 当使用
iframe时，其内部的文档拥有完全独立于父页面的堆叠上下文体系，父页面中的z-index无法控制 iframe 内部元素的层级。 - 在通过 CSS 变量或 Ja vaScript 动态生成样式的场景中，如果
z-index的值被计算为NaN或空字符串，浏览器通常会将其当作auto来处理，效果等同于未设置。
话说回来，真正困难的往往不是写下一个 z-index 数值，而是准确地识别出当前元素究竟属于哪个堆叠上下文。这通常需要打开浏览器的开发者工具，在 Computed 面板里逐层检查元素的 z-index 以及是否存在堆叠上下文的标识，才能理清复杂的层级关系。
