Sass的$z-index-map不能解决导航层级错乱，因为它只是编译期静态映射，不感知运行时层叠上下文变化，如父级加transform会创建新上下文，使子菜单z-index失效。
为什么Sass的$z-index-map不能解决导航层级错乱
它只是编译期静态映射，不感知运行时层叠上下文变化。比如一个.submenu设了z-index: map-get($z-index-map, dropdown)，但它的父级.nav-item加了transform: translateY(0)，立刻创建新层叠上下文——子菜单的z-index只在该局部生效，再大也盖不过同级.header里的z-index: 800。
常见错误现象：
- 鼠标悬停后子菜单闪一下就消失
- 移动端点开二级菜单，内容被顶部
sticky导航盖住 - 用
createPortal把菜单挂到body，结果和modal打架
真正需要的不是Map，而是语义化常量 + 运行时控制
Sass $z-index-map唯一合理用途是定义命名空间和初始值，但必须导出为 CSS 自定义属性，供 JS 动态读写。否则它只是“看起来工程化”的幻觉。
实操建议：
- 在
_variables.scss中定义$z-nav: (base: 10, dropdown: 200, mega-menu: 300); - 用
:root { --z-nav-base: #{map-get($z-nav, base)}; --z-nav-dropdown: #{map-get($z-nav, dropdown)}; }输出为 CSS 变量 - 导航组件内写
z-index: var(--z-nav-dropdown);，而非直接调 Sass 函数 - JS 需要临时提层（如 hover 时下拉菜单上浮）时：
el.style.setProperty('--z-nav-dropdown', '250');
多级导航必须守住的三个定位边界
层级管理失效，90% 是因为没守住在 DOM 和 CSS 层面的三层锚点。
-
.nav-item必须设position: relative，否则.submenu的absolute会相对于body定位，脱离预期参考系 -
.submenu自身要设position: absolute且z-index显式大于0（不能依赖auto） - 整个导航容器（如
.main-nav）不能有opacity 、will-change: transform或filter，否则会静默截断所有子菜单的全局层叠能力
移动端:focus-within方案下z-index怎么配
用:focus-within替代:hover时，z-index逻辑不变，但触发时机变了：焦点进入父容器才激活子菜单，此时必须确保父容器本身可聚焦（tabindex="0"），且未被overflow: hidden裁切。
关键细节：
- 给
.nav-item加tabindex="0"，否则:focus-within永不触发 -
.submenu的z-index值需高于页面其他可能获得焦点的元素（如input、button），推荐不低于--z-nav-dropdown的两倍 - 避免在
.nav-item:focus-within .submenu里用transition: opacity，opacity变化会触发新层叠上下文，导致菜单在淡入过程中短暂被盖住
最易被忽略的是：当导航嵌套在transform: scale(0.95)的容器中时，整个导航树会成为一个独立层叠上下文——这时改.submenu的z-index毫无意义，得去动容器的transform或换用scale以外的缩放方式。
