Less不支持原生CSS嵌套语法，混用会报ParseError；必须区分.less（用&拼接）和.css（用@nest或现代浏览器支持）文件，不可共存。
Less文件里混用原生CSS嵌套会直接报错
Less解析器根本不认识@nest、& a这种原生嵌套写法，遇到就抛ParseError: Unrecognised input。这不是兼容性问题，是语法层面不支持——Less和原生CSS嵌套是两套互斥的编译逻辑，不能共存于同一文件。
常见踩坑点：
- 复制网上“CSS原生嵌套”示例代码（如
nav { & a { } }）粘贴进.less文件，编译立刻失败 - 以为
&在Less和原生CSS里行为一致，结果在Less里写&:hover没问题，但写& a却意外编译成.btn a（正确），而原生写法a { }在Less里会被当普通选择器，脱离上下文变成全局a - VS Code插件自动补全或AI生成代码时，默认输出原生嵌套语法，没注意文件后缀是
.less
Less项目中想用原生嵌套语法，只能换文件后缀
真要尝鲜原生CSS嵌套，必须把文件从.less改成.css，并确认构建工具支持postcss-nesting或现代浏览器目标（Chrome 112+ / Safari TP 162+）。但这就放弃了Less所有特性：变量、mixin、@import逻辑、&拼接等。
实际可行路径：
立即学习“前端免费学习笔记（深入）”；
- 业务组件样式继续用
.less，靠&__element写BEM，稳定可靠 - 纯展示型页面或实验性模块，新建
.css文件，用nav { a { } }写法，但得手动处理变量（改用CSS自定义属性）、无条件编译 - Webpack中若同时处理
.less和.css，确保postcss-loader只对.css启用postcss-nesting，否则.less经less-loader编译后再进postcss会二次解析出错
Less里模拟原生嵌套效果，其实更可控
原生嵌套想实现的“子选择器相对父级”，Less早就能做，只是写法不同。关键不是模仿语法，而是达成同样目的：减少重复前缀、避免手误漏写父类。
推荐做法：
- 用
&拼接类名：.card { &__header { } &__body { } }→ 编译为.card__header/.card__body，物理隔离，无歧义 - 后代选择器显式空格：
.list { .item { } }→.list .item，语义清晰，权重可控 - 子元素用
>：.list { > .item { } }→.list > .item，避免意外命中深层嵌套 - 伪类必须带
&：&:hover，不写:hover，否则变成全局:hover
多人协作时，统一约定比语法争论更重要
Less团队突然有人提“我们改用原生嵌套吧”，往往引发构建链路重配、CI失败、老成员看不懂新写法等问题。真正成本不在语法本身，而在工具链适配和认知同步。
更务实的做法：
- 项目根目录放
LESS_STYLE_GUIDE.md，明确写死：&__用于BEM元素，&--用于修饰符，禁止在.less里出现@nest或裸a { } - CI加校验：用
grep -r '@nest\|& a\|a {' src/**/*.less，命中即fail - VS Code配置
files.associations，确保.less文件只用Less语言服务，关掉CSS智能提示干扰
Less的&和原生CSS的&看起来一样，但背后是两套完全不同的解析器。别指望它们互相理解，也别强行嫁接——选一条路，走到底。
