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 要生效，三个条件缺一不可：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 目标元素自身必须有
position（relative/absolute/fixed），static下设z-index完全无效 - 它的最近定位祖先（通常是
.menu-item）必须是position: relative，否则absolute子菜单会飞到html或body下定位 - 该祖先及其所有上级容器，不能意外创建 stacking context：检查是否带
transform、opacity 、<code>filter、will-change——哪怕只加了一行transform: translateY(0)，整个子菜单的z-index就锁死在局部上下文中
SCSS 只做语义锚点，不参与运行时决策
把 SCSS 当作“命名字典”，而非“层级引擎”：
- 在
_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。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
