z-index管理多级下拉菜单不能依赖SCSS静态排序，因其无法感知运行时stacking context；必须确保目标元素设position、最近祖先为position: relative，且各级父容器不触发opacity/transform/filter等隐式层叠上下文。

z-index 管理多级下拉菜单，不能靠 SCSS 列表排序或嵌套计算来“优雅”解决——它在编译期就固化为静态数字，对运行时层叠上下文（stacking context）完全无感。你看到的“层级顺序”，只是 CSS 文件里的一串数字，不是浏览器实际绘制时的树状嵌套关系。

---

z-index 失效时的典型现象

• 鼠标悬停后 .submenu 闪一下就消失
• 移动端点开二级菜单，被 .header（position: sticky）盖住
• 三级菜单从右侧展开，却卡在二级菜单内部无法浮出
• Modal 内嵌 Dropdown，再大的 z-index 也出不来

这些都不是数值不够大，而是：

• 父容器触发了新 stacking context（如 transform、opacity: 0.99、will-change）
• .submenu 的定位参考系错位（没给 .menu-item 设 position: relative）
• Portal 类挂载（如 Teleport 到 body）后，body 缺少 position: relative 和 z-index: 0

---

必须守住的三层 DOM/CSS 锚点

z-index 要生效，三个条件缺一不可：

• 目标元素自身必须有 position（relative / absolute / fixed），static 下设 z-index 完全无效
• 它的最近定位祖先（通常是 .menu-item）必须是 position: relative，否则 absolute 子菜单会飞到 html 或 body 下定位
• 该祖先及其所有上级容器，不能意外创建 stacking context：检查是否带 transform、opacity < 1、filter、will-change ——哪怕只加了一行 transform: translateY(0)，整个子菜单的 z-index 就锁死在局部上下文中

---

SCSS 只做语义锚点，不参与运行时决策

把 SCSS 当作“命名字典”，而非“层级引擎”：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

立即学习“前端免费学习笔记（深入）”；

• 在 _z-index.scss 中定义：$z-nav: (base: 10, dropdown: 200, mega-menu: 300);
• 用 :root 导出为 CSS 变量：--z-nav-dropdown: #{map-get($z-nav, dropdown)};
• 组件内直接使用：z-index: var(--z-nav-dropdown);，不要调 map-get()
• JS 需要 hover 提层时：el.style.setProperty('--z-nav-dropdown', '250');

这样既保留集中维护能力，又把真实控制权交给运行时。如果非要用 SCSS 变量，必须配合 @use 显式引入并带命名空间，比如：z.$z-nav-dropdown，否则作用域断链，值根本不会进编译结果。

---

复杂点从来不在怎么排数字，而在于 stacking context 是隐式、嵌套、由多个 CSS 属性共同触发的——你没法靠一张 SCSS 列表穷举所有组合。真正要调试的，永远是「Computed」面板里那个灰掉的 z-index 值，和它上面第 3 层父元素的 transform。