less中&报错需先确认编译器版本（≥3.13.1）、语法规范（&紧贴选择器无空格）、工具链兼容性（如less-loader与less匹配）、禁用干扰选项（如javascriptenabled: true）及压缩工具误删问题。
Less嵌套中&报错，先确认编译器是否支持该语法
Less的&是编译期特性，不是所有工具链都默认启用或兼容。比如老版本lessc 2.x或某些嵌入式编译器（如Qt的webcompiler）可能只支持CSS-like子选择器写法，遇到&__item直接抛ParseError: Unrecognised input。
检查方法很简单：lessc --version，低于3.13.1的版本对&拼接类名（尤其是BEM风格）支持不完整；4.0+才稳定支持& + &、& ~ &等组合用法。
- Vue项目中用
less-loader，需同时检查less和less-loader版本：二者需匹配，例如less-loader@11要求less@4，否则&在@media内或嵌套mixin中会静默失效 - Webpack配置里若启用了
lessOptions.javascriptEnabled: true，反而可能干扰&解析逻辑——这不是必须项，多数场景应设为false - Qt
webcompiler这类非标准工具，根本不识别&，报错行号常不准；建议先用lessc单独编译验证，再决定是否降级写法
&后面漏空格或写错位置导致编译失败
Less对&的语法非常敏感：&必须紧贴选择器，中间不能有空格，也不能孤立存在。常见错误包括&--primary{}（缺空格）、& :hover{}（伪类前多空格）、.btn{&.active{}}（&.active会被当做一个新类名而非拼接）。
-
.btn { &--primary { } }→ 正确，输出.btn--primary -
.btn { & --primary { } }→ 错误，&脱离上下文，多数编译器报ParseError或忽略整块 -
.card { &:hover { } &::before { } }→ 正确；但写成&: hover（冒号后空格）或&:before（少一个:）都会失效 - 在
@media查询内部直接写&会失败：@media (max-width: 768px) { & { color: red; } }非法；必须先有外层选择器，再进媒体查询内用&
嵌套层级过深或跨区域使用&引发兼容性问题
&只代表**紧邻上一级选择器**，不会跨层继承。三层嵌套时，第二层可用&，第三层必须再套一层&，不能靠一个&跳两级。某些旧编译器（如lessc 3.0）甚至拒绝解析含多层&的表达式。
-
.list { .item { &__text { } } }→ 输出.list .item__text，不是.list__text；想生成后者得写.list { &__text { } .item { } } - 混用BEM修饰符和
&时容易出错：.btn--large { &__icon { } }输出.btn--large__icon，符合预期；但若本意是.btn__icon--large，就不能硬套&，得改用变量或拆开写 - CSS原生嵌套（
@nest）和Less的&互不兼容。如果项目部分用.module.css走原生嵌套，别试图让&和@nest共存于同一文件——构建工具（Vite/webpack）压根不识别对方语法
压缩工具二次处理导致&生成的选择器被误删
Less编译完的CSS是纯文本，后续若经cssnano等压缩器处理，长选择器（如.header__nav__item__link:hover）可能被判定为“低优先级”而删掉，尤其当配置了reduceTransforms: true或discardDuplicates: true时。
- 检查构建产物CSS文件，搜索编译前写的
&__xxx对应的选择器是否存在；若缺失，大概率是压缩阶段干的 - 在
cssnano配置中显式禁用相关规则：{ reduceTransforms: false, discardDuplicates: false } - 避免生成过深拼接：
&__body__title__highlight这种四级拼接既难读又易被压缩器误伤，3层已是实用红线
真正麻烦的不是&本身，而是它把「编译期展开」这个事实藏得太深——你看到的是缩进和符号，实际产出的是硬编码的选择器字符串。一旦编译器版本不对、空格多一个、或者压缩器插一脚，结果就和预期差很远。
