z-index失效本质是层叠上下文隔离，而非数值问题；必须确保目标元素及其祖先未被opacity
z-index 在 Less 中写得再整齐，只要触发了意外的层叠上下文，照样失效。 本质不是变量没传过去，而是你写的 z-index 被锁在某个父级创建的“小房间”里，根本出不去。
为什么 Less 变量 + z-index 还是盖不住兄弟元素
常见现象：用 @modal-z: 9998 定义好值，.modal { z-index: @modal-z; } 也写了，但弹窗仍被导航栏遮住。原因几乎总是——导航栏父容器（比如 .header）悄悄带了 transform: translateY(0) 或 opacity: 0.99，隐式创建了新的层叠上下文，把它的子元素全圈进去了。
- 检查浏览器开发者工具的「Layers」面板（Chrome）或「Computed」里的「Stacking Context」字段，看目标元素是否处于预期的上下文中
- 用
getComputedStyle(el).getPropertyValue('z-index')读出来的值是"auto"？说明它压根没进入可排序的层叠环境 - Less 变量只是编译时替换，它不阻止、也不感知层叠上下文的生成——该塌房时一样塌
Less 中用 Map 管理 z-index 的三个硬限制
Less 的 @z-index-map 看似方便，但直接套用容易踩坑：
- Map 的 key 必须加引号：
"modal"✅，modal❌（Less 解析失败） - value 必须是纯数字：
9998✅，9998px或calc(1000 + 1)❌（编译报错） -
.each()生成的类名是.z-modal，但如果你的组件结构里.modal是子元素，而父容器已建层叠上下文，那这个类就只在父容器内部起作用——别指望它能跨出去盖过隔壁.sidebar
导出 CSS 变量时，z-index 不是“设一次就完事”
很多人把 Less 变量转成 --z-modal: 9998 就以为搞定了，结果 JS 动态改了变量值，页面层级纹丝不动。因为：
- CSS 自定义属性本身不参与层叠计算，它只是个字符串容器
- 你必须显式写规则：
.modal { z-index: var(--z-modal); }，否则--z-modal再准也没用 - JS 修改后，若浏览器没重绘（尤其某些 Chrome 版本），要手动触发 reflow，比如读取
el.offsetHeight
真正安全的层级控制，靠的是结构+变量双约束
变量管数值，结构管上下文范围。最容易被忽略的一点是：**z-index 生效的前提，不是“我写了”，而是“我属于哪个层叠上下文，以及这个上下文本身有没有资格参与全局排序”。**
- 给关键容器（如
.app、.layout）设position: relative+z-index，让它成为“顶层调度中心” - 所有模态类、弹窗、浮层都挂在这个容器下，避免各自为政建上下文
- Less 中仍用
@z-modal控制逻辑，但编译后必须落到具体选择器上，且该选择器的定位上下文路径清晰可追溯
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
