Less 的 mixin 本身不能管理 z-index，真正可控的是变量常量池 + 带参数的 .z() mixin；它通过语义化关键词查表、支持偏移、校验输入，强制约束调用入口，避免裸写数字导致的层级混乱。
直接说结论：Less 的 mixin 本身不能“管理” z-index，它只是编译时的代码复用工具；真正起作用的是你用 @z-index 变量定义的层级常量池 + 带参数的 .z() mixin 封装调用逻辑。否则容易在多人协作中出现 z-index: 9999 滥用、覆盖混乱、重构困难等问题。
为什么不能只靠变量？得配 mixin 才可控
只定义一堆 @z-modal: 1000; 这类变量看似清晰，但实际开发中：设计师改需求、新弹窗加一层、临时覆盖写 z-index: 1001 —— 很快就失控。Mixin 的价值在于强制约束调用入口，把“赋值动作”收口到一个函数式接口里。
实操建议：
- 所有 z-index 赋值必须通过
.z(modal)这类调用，禁止直接写数字 - 在 mixin 内部做校验（比如非预期关键词报 warning）或自动叠加（
.z(modal, +1)） - 变量池集中放在
_z-index.less，只导出不直接使用
怎么写一个带常量池和安全检查的 .z() mixin
核心是让 .z() 接受语义化关键词（如 tooltip、dropdown），查表返回对应值，并支持偏移。避免硬编码数字暴露在业务样式里。
示例（精简版）：
@z-base: 0;
@z-tooltip: 100;
@z-dropdown: 200;
@z-modal: 1000;
@z-overlay: 999;
.z(@layer, @offset: 0) when (isnumber(@offset)) {
z-index: ~"@{z-@{layer}}" + @offset;
}
// 使用时：
.btn { .z(tooltip); } // → z-index: 100;
.popover { .z(dropdown, +10); } // → z-index: 210;
注意：~"@{z-@{layer}}" 是 Less 动态变量拼接的关键语法，漏掉波浪号会编译失败；when (isnumber(@offset)) 防止传入非法偏移值。
常见错误：命名冲突、拼写敏感、未处理未知 layer
实际项目里最容易踩的坑不是语法，而是协作时的隐性约定破裂：
- 不同模块各自定义
@z-header，值却不一样 → 必须统一收口到单个文件，且用@import (once) - 调用
.z(Tooltip)（首字母大写）→ 变量名是@z-tooltip，匹配失败，编译后无z-index输出，样式丢失且无报错 - 传了未知关键词如
.z(slider)，Less 默认静默失败 → 加上兜底逻辑：.z(@layer) when not (ispixel(@z-@{layer})) { warning("Unknown z-layer: @{layer}"); }
真正难的不是写对这个 mixin，而是推动团队所有人删掉所有裸写的 z-index 数字，并接受“必须查表”的约束。一旦漏掉一处，整个层级体系就可能从那个点开始塌方。
