z-index 失效主因是未设置定位属性或父容器创建了新层叠上下文；应通过语义化常量（如 sass 变量或 js 单一源）统一管理，并理清层叠上下文边界。
z-index 值为什么一加就失效？
CSS 中 z-index 失效，往往不是写错了，而是没在定位上下文里。只有 position 为 relative、absolute、fixed 或 sticky 的元素，z-index 才生效。更隐蔽的问题是：父容器的 z-index 会截断子元素的层叠范围——即使子元素设了 z-index: 9999，也永远无法盖过父容器所在层叠上下文之外的兄弟元素。
- 确保目标元素有显式
position声明（不能只靠z-index） - 检查其最近的「定位祖先」是否意外设置了
z-index（哪怕只是z-index: 0），这会创建新的层叠上下文 - 避免用超大魔数（如
z-index: 999999）掩盖结构问题；它只会让后续覆盖更难协调
CSS 中怎么定义可维护的 z-index 常量？
纯 CSS 不支持变量常量，但现代工程中可通过 CSS 自定义属性（:root 变量）或预处理器（如 Sass）实现语义化层级管理。关键是把数字映射成含义，而非位置。
使用 Sass 示例（推荐，编译期校验强）：
$z-modal: 1000; $z-dropdown: 900; $z-sticky-header: 800; $z-tooltip: 700; $z-default: 1;
然后在组件中写 z-index: $z-modal;。这样：
- 修改全局层级只需改一处变量
- 新增组件时能快速判断该用哪个层级（比如弹窗不该低于下拉框）
- 避免多人协作时随意写
z-index: 1234导致冲突
注意：Sass 变量无法被 JS 读取；若需运行时控制（如动态弹窗栈），得同步维护 JS 端常量对象。
为什么 CSS-in-JS 或 Tailwind 用户仍要管 z-index？
Tailwind 的 z-0 到 z-50 是线性步进，不带语义。项目一旦出现模态框嵌套下拉菜单再浮一层 Tooltip，就会发现 z-50 不够用，又不敢随便升到 z-60——因为没人知道 z-60 被谁占了。
CSS-in-JS（如 Emotion、Styled-components）虽支持 JS 变量，但容易分散定义：
- 某个 Modal 组件里定义
zIndex: 1000 - 另一个 Dropdown 在 hooks 里又写
zIndex: 999 - 最终谁高谁低取决于 JS 执行顺序，不可控
正确做法是：所有 z-index 值必须从单一源导出，例如：
// z-index.ts
export const Z_INDEX = {
backdrop: 100,
dropdown: 200,
tooltip: 300,
modal: 1000,
} as const;
然后各处统一引用 Z_INDEX.modal，连类型提示都能约束赋值范围。
引入顺序会影响 z-index 吗？
纯 CSS 文件引入顺序本身不直接影响 z-index 计算，但会间接决定「谁先创建层叠上下文」以及「同级元素的层叠顺序」。
- 如果两个同级
div都设了position: relative和z-index，后引入的 CSS 规则若选择器权重相同，会覆盖前面的值 - 更关键的是：HTML 中元素 DOM 顺序 + 层叠上下文创建时机，共同决定默认层叠层（painting order）。例如两个无
z-index的fixed元素，后面渲染的会盖在前面的上面 - 所以规范里必须明确：「基础层叠上下文容器（如 Layout、Header）的 CSS 必须最先引入」，否则业务组件可能无意中把自己塞进错误的层叠栈
真正容易被忽略的，是把 z-index 当成孤立数值去调，而忘了它永远活在层叠上下文的嵌套树里。定常量只是第一步，理清上下文边界才是根治混乱的关键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
