Less多层嵌套需用&引用父选择器，避免过深（三层以上）导致高特异性和难维护；应主动用&__xxx构建BEM命名空间，而非依赖缩进模拟DOM深度。
Less里怎么写多层嵌套选择器
Less原生支持CSS选择器的层级嵌套，但必须注意：它只展开语法结构，不改变最终生成的选择器权重或特异性。写 & > .child 和直接写 .parent > .child 编译结果一样，但前者更易维护。
常见错误是以为嵌套能“自动降权”或“隔离样式”，其实不会——嵌套越深，生成的选择器 specificity 越高，越难被覆盖。
- 用
&引用父选择器，避免重复写类名，比如.card { &__header { color: #333; } }编译为.card__header - 子选择器用
& > .item，而非> .item（后者会被当成新规则，编译出错） - 相邻兄弟选择器写成
& + .sibling，不要漏掉& - 慎用三层以上嵌套，如
.a { .b { .c { ... } } }会生成.a .b .c，容易意外命中深层DOM，也难调试
嵌套时怎么避免生成过长的选择器链
Less嵌套本身不压缩输出，每层都会叠加父级选择器。一个 .modal { .header { .title { font-size: 16px; } } } 会变成 .modal .header .title，而不是你想要的 BEM 风格的 .modal__title。
真正可控的方式是主动用 &__xxx 或 &--modifier 构建命名空间，而不是依赖视觉缩进模拟DOM深度。
立即学习“前端免费学习笔记（深入）”；
- 用
&__body替代.body嵌套，确保输出类名扁平、可预测 - 如果DOM结构固定且深层，优先提取独立组件类（如
.table-cell-actions），而不是靠嵌套推导 - 开启 Less 的
--strict-math=on不影响嵌套，但能防止意外的算术运算干扰选择器生成 - 检查编译后CSS，确认没有出现类似
.page .layout .content .section .item这种7级+选择器——这种几乎无法被局部覆盖
为什么有时候嵌套编译出的选择器顺序不对
Less按源码书写顺序展开嵌套，但CSS层叠规则仍以最终选择器权重和位置为准。如果你在嵌套块里混用了 @media、:hover 或变量引用，展开时机可能打乱预期顺序。
典型现象：hover样式没生效，查DOM发现 hover 规则被写在了普通状态后面，但因为 specificity 相同，后定义的反而覆盖了前面的。
-
&:hover必须紧跟在父选择器块内，不要跨行或夹杂其他逻辑 - 媒体查询写在嵌套内部时，用
@media (min-width: 768px) { &__nav { ... } }，别把@media单独提一层再嵌套 - 避免在嵌套中调用未定义变量，Less会静默忽略该条规则，导致样式“消失”却无报错
- 使用
lessc --lint可提前发现嵌套语法问题，但不会警告 specificity 冲突
Vue / React 项目里要不要用Less嵌套管DOM深度
不要。现代框架的组件作用域（scoped 或 CSS Modules）已解决样式泄漏问题，嵌套反而增加理解成本和维护负担。
比如 Vue 单文件组件中写 <style lang="less" scoped>，Less嵌套生成的选择器会被自动加属性选择器（如 .btn[data-v-f3f3eg9]），此时再套三层嵌套，既无必要，又让 DevTools 中的样式来源难以追踪。
- 组件内样式优先用单层类名 + BEM，如
.dialog__footer，而非.dialog { .footer { ... } } - 需要响应深层DOM结构时（如第三方富文本编辑器输出的
<p><span><strong>），用属性选择器或:deep()（Vue）/:global()（Less）显式穿透，比靠嵌套猜结构更可靠 - 全局工具类（如
.text-sm、.flex-center）禁止嵌套，它们本就该扁平、可组合
嵌套不是银弹，它省的是键盘敲击，换来的可能是重构时不敢动的“祖传选择器”。真要处理深度DOM，先看能不能用数据驱动替换节点结构，再考虑样式方案。
