Less中&必须紧跟选择器后且用空格隔开才能正确拼接父名，仅代表紧邻上一级选择器，不跨层，伪类伪元素需写全（如&:hover），BEM修饰符需注意拼接逻辑，不兼容CSS原生@nest，嵌套过深影响可维护性。
Less中&怎么正确嵌套父选择器
直接写&不会自动拼接父名，必须跟在选择器后面、用空格隔开，否则编译报错或结果不对。比如.btn { &--primary { color: blue; } }会输出.btn--primary，但写成.btn { &--primary{...} }（中间没空格）多数Less版本会忽略或报ParseError。
-
&只代表**紧邻的上一级选择器**，不跨层。嵌套三层时，第二层用&，第三层得再套一层&，不能靠一个&跳两级 - 伪类、伪元素要写全：
&:hover、&::before，漏掉冒号或写成&: hover（空格）会失效 - 如果父选择器带属性或类组合，如
.card.is-active，&.expanded会生成.card.is-active.expanded，不是.card.is-active .expanded（注意有无空格）
用&替代重复类名时的常见错误
手写重复类名容易漏改、难维护，但盲目用&也可能产出冗余CSS。比如.header { &-title { ... } &-nav { ... } }看着干净，可一旦.header本身是动态加的（如.header.theme-dark），&-title就无法继承主题类——它只认字面父级，不认运行时状态。
- 不要在
@media查询里直接用&，像@media (max-width: 768px) { & { ... } }会报错；正确写法是先定义外层选择器，再在媒体查询内用& - 当父选择器含BEM修饰符（如
.btn--large），&__icon会生成.btn--large__icon，符合BEM，但若原意是.btn__icon--large，就得换写法，不能硬套& - 多个并列选择器共用同一嵌套块时，
&只绑定最近的一个父级，不会广播到所有前面的父选择器
与CSS原生嵌套（@nest）的兼容性差异
新版Chrome和Safari已支持CSS nesting（草案），语法类似.card { @nest &__title { ... } }，但Less的&不依赖运行时，是编译期展开。这意味着：你不能指望Less编译出的CSS能被浏览器原生嵌套解析器识别，反之亦然。
- Less的
&支持任意层级拼接，包括& + &、& ~ &等组合，而原生@nest目前只允许&出现在选择器开头且后跟子/伪等关系符 - 如果项目同时用Less和原生CSS模块（比如部分组件用
.module.css），别试图让&和@nest混写，编译工具（如Vite、Webpack）对两者的处理链路完全不同 - 构建时若启用了CSS压缩（如cssnano），嵌套生成的长选择器可能被误判为低优先级而删掉，建议检查压缩配置是否保留
reduceTransforms: false等选项
什么时候不该用&——性能与可读性的临界点
嵌套过深会让开发者难以快速定位样式来源，尤其在多人协作项目里。&本身不增加运行时开销（编译后就是普通CSS），但写到5层以上，排查一个margin到底被哪条规则覆盖，比看扁平结构多翻三屏。
立即学习“前端免费学习笔记（深入）”；
- 组件级样式建议控制在3层以内：组件名 → 元素 → 状态（如
.dialog { &__content { &:focus { ... } } }） - 全局工具类（如
.text-center、.m-2）禁止用&嵌套，它们本该是原子化、无上下文的 - 涉及JavaScript动态切换的类（如
.is-open、.has-error），与其用&.is-open，不如单独抽成.component.is-open &__trigger，更利于调试和复用
&省的是键盘敲击，不是思考成本。真正卡住人的，从来不是怎么写嵌套，而是某天发现.sidebar.is-collapsed &__item没生效，结果查了半小时才发现是JS没加那个is-collapsed类——而这个事，&帮不上忙。 
