Less嵌套不改变CSS选择器顺序，只影响结构与权重；优化层级靠&显式拼接和深度约束，非书写顺序；空格是语法分界符，&后有无空格决定选择器类型；超两层嵌套恶化权重与性能；BEM类名实现扁平化；媒体查询中漏&导致全局污染。
Less嵌套本身不改变CSS选择器的“顺序”，它只影响编译后选择器的**结构**和**权重**；所谓“优化层级”，本质是控制输出的选择器是否扁平、是否可覆盖、是否语义清晰——不是靠调整嵌套书写顺序，而是靠&的显式拼接逻辑和嵌套深度约束。
为什么改书写顺序没用？
Less在编译期把所有嵌套展开为字符串拼接，不保留代码行序或缩进逻辑。比如：
.card {
.header { color: red; }
.footer { color: blue; }
}
无论.header写在前还是.footer写在后，编译结果都是：
.card .header { color: red; }
.card .footer { color: blue; }
顺序由源码书写位置决定，但这个顺序对浏览器匹配无影响，也不改变特异性。真正起作用的是：&是否出现、空格是否存在、嵌套是否超过两层。
立即学习“前端免费学习笔记（深入）”；
&后有无空格直接决定选择器类型
这是最常踩坑的点：空格不是格式问题，是语法分界符。
-
&.is-active→ 编译为.btn.is-active（并列类，权重低，推荐） -
& .icon→ 编译为.btn .icon（后代选择器，权重高，易冲突） -
&:hover→ 正确，生成.btn:hover -
& :hover→ 错误，Less解析为标签选择器，报Unknown word
伪类/伪元素必须紧贴&，中间不能有空格；拼接子类名也一样，&__body才生成.card__body，写成& __body就变成全局__body了。
嵌套超两层会实质性恶化CSS层级
三层嵌套如.card { .header { .title { } } }，编译后是.card .header .title，权重0-3-0，比.card__header__title（0-0-1-0）高出三倍，且浏览器匹配成本陡增。
- 移动端WebView中，四层嵌套选择器样式计算耗时上升40%+
- 一旦出现
.page .layout .content .section .item这种5级输出，说明该拆组件，不是该调顺序 - BEM类名（
&__title、&--disabled）才是可控的“扁平层级”，不是缩进嵌套
想让.btn在.is-disabled状态下控制.icon，别写三层嵌套，写成：.btn { &.is-disabled { &__icon { } } }，输出.btn.is-disabled .btn__icon，权重合理、定位明确。
媒体查询里漏&等于放弃父级绑定
@media块内不写&，嵌套内容就脱离上下文，变成全局规则。
@media (max-width: 768px) {
.nav {
& a { color: #007bff; } // ✅ 编译为 @media {...} .nav a
a { color: #dc3545; } // ❌ 编译为 @media {...} a（匹配全站所有a）
}
}
尤其当嵌套多于一层时（如.nav { li { a {} } }），漏&会导致调试时完全找不到样式来源——浏览器开发者工具里看到的只是孤立的a，而非.nav a。
嵌套是给人读的，不是给浏览器加速的；每次敲{前，得确认：这个结构是靠&显式收束的，还是靠空格隐式放大的？后者几乎总是错的。
