less嵌套应仅表达视觉结构，避免选择器爆炸：限单层嵌套、用&显式拼接、拆分多级状态；用语义化z-index变量和无嵌套mixin解耦层叠；交互状态优先用class而非伪类；@import顺序决定层叠，全局变量须最先引入。
Less嵌套怎么避免选择器爆炸
嵌套写多了，编译出来一堆冗长选择器，不仅体积涨、优先级失控，还容易被后来的CSS覆盖。核心是：嵌套只用于表达「视觉结构」，不用于复用或逻辑分组。
实操建议：
- 单层嵌套够用就别嵌第二层——比如
.card { .card-header { ... } }合理，但.card { .card-header { .icon { .icon--small { ... } } } }就危险了 - 用
&显式控制父选择器拼接位置，避免隐式叠加：.btn { &.is-active { ... } }编译为.btn.is-active，而不是.btn .is-active - 遇到多级状态组合（如
.modal.is-open .overlay.is-fading），宁可拆成两个独立规则，也不用三层嵌套硬凑
如何用Less变量和混合（mixin）解耦层叠依赖
组件内部层级关系常随状态变化而切换（比如弹窗展开时遮罩层要盖住导航栏），靠纯嵌套很难维护。这时候变量和 mixin 不是锦上添花，而是隔离层叠逻辑的刚需。
实操建议：
- 把 z-index 值抽成变量，按语义命名：
@z-modal: 1000;、@z-overlay: 999;，而非@z-1: 1000; - 用 mixin 封装「提升层级」行为：
.lift-layer(@level) { z-index: @level; }，在需要的地方调用.lift-layer(@z-modal); - 避免在 mixin 内部写嵌套选择器——它会让调用点的层叠上下文变得不可预测
嵌套里用 &:hover 和 &.is-open 的优先级陷阱
Less嵌套中写 &:hover 看似方便，但实际会放大选择器权重。比如 .dropdown { &:hover { .menu { display: block; } } } 编译后是 .dropdown:hover .menu，比 .dropdown.is-open .menu 权重更高，后期想用 class 控制状态反而被 hover 锁死。
实操建议：
- 交互状态统一用 class 控制（
.is-hovered、.is-open），再配合 JS 切换，避免伪类干扰层叠流 - 如果必须用
:hover，确保它只出现在最外层组件选择器上，不要嵌套进子元素规则里 - 检查编译后 CSS 的 specificity，可用浏览器开发者工具的「Computed」面板看
z-index是否真被应用，而不是被更高权重要求覆盖
Less作用域与 @import 顺序对层叠的影响
Less 不是运行时解析，而是编译时扁平化。@import 顺序直接决定 CSS 规则的书写顺序，而层叠恰恰依赖这个顺序。很多人以为嵌套能“自带作用域”，其实不能。
实操建议：
- 组件 Less 文件里不要
@import全局变量以外的样式——尤其别在.dialog.less里@import "button.less"，否则按钮样式会插进 dialog 规则中间，打乱预期层叠 - 全局 z-index 变量必须在所有组件前
@import，否则不同文件里引用的@z-modal可能不是同一个值 - 用
//注释标出关键层叠断点，例如：// === z-index boundary: overlay sits below modal ===，提醒后续维护者别跨过这条线加新规则
层叠不是写得深就管用，而是谁先声明、谁权重低、谁被 JS 动态加 class，这些细节一错，嵌套再漂亮也压不住真实渲染结果。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
