z-index生效需满足两个硬性条件：一是元素必须设置position: relative/absolute/fixed/sticky（非static），二是不能被父级层叠上下文隔离——子元素z-index仅在其最近的层叠上下文中生效，跨上下文时由父级z-index决定层级。
要让 z-index 真正起作用，得先让它“能干活”——不是写了就生效，而是得满足两个硬性条件：元素必须定位，且不能被父级堆叠上下文锁死。
确保元素已进入“可控制层级”的状态
z-index 只对 position: relative、absolute、fixed 或 sticky 的元素有效。默认 position: static 的元素，哪怕写上 z-index: 9999，浏览器也直接忽略。
- 最常用也最安全的做法是加 position: relative——它不改变元素在文档流中的位置，但能激活 z-index
- 避免只靠父容器定位来“捎带”子元素：子元素的 z-index 是相对于最近的**已定位祖先**生效，不是全局通用
- 检查 computed styles，确认目标元素的 position 不是 static，z-index 也不是 auto（auto 相当于未参与层叠排序）
避开父级堆叠上下文的隐形限制
即使子元素 z-index 写得再大，一旦它的某个祖先创建了新的堆叠上下文，子元素就被“关进小房间”，只能跟同屋的兄弟比高低，出不了门。
- 常见触发新堆叠上下文的属性包括：opacity 、transform（如 translateZ(0)、scale(1)）、filter、will-change、isolation: isolate
- 典型现象：给弹窗容器加了 transform 做硬件加速，结果弹窗被隔壁带 filter 的卡片盖住——因为卡片自己建了个上下文，把弹窗“框死”在里面
- 调试方法：用 Chrome DevTools 的 Layers 面板看上下文边界；或临时删掉可疑样式验证是否恢复
合理设置 z-index 数值，避免数字竞赛
数值大小本身不决定全局谁在上，只决定**在同一堆叠上下文内**谁更靠前。跨上下文时，起决定作用的是父级的绘制顺序。
- 不要用 z-index: 9999 这类魔法数字——容易失控，也掩盖结构问题
- 按功能分层管理，例如：--z-toast: 100、--z-dropdown: 200、--z-modal: 1000，留出空档方便扩展
- 负值可用，但会让元素沉到父容器背景色之下（如果父容器有背景，就会看不见）
- 用 CSS 自定义属性统一定义，便于项目维护和主题切换
绕过限制的实用替代方案
当 z-index 调整变得复杂或不可靠时，换种思路往往更高效。
- 把需要置顶的元素（如 Toast、Tooltip、全屏遮罩）动态 append 到 底部——天然脱离原有上下文，靠 DOM 顺序就能保证在最上层
- 用 isolation: isolate 主动创建堆叠上下文，比依赖 transform/opacity 等副作用更清晰、更可控
- Flex 或 Grid 容器内的直接子项支持 z-index，但注意：若子项内部再设 absolute 定位，其后代就回归标准规则，不再继承父容器的层叠逻辑
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
