中小型前端项目应选 Sass（.scss），因其构建更稳定、变量作用域更安全、错误提示更精准、团队协作容错更强；dart-sass 编译可靠，$ 变量块级作用域，@use 模块化避免污染，VS Code 支持更好，认知成本更低。
.scss 语法），不是因为它“更高级”，而是它在构建稳定性、变量作用域控制、错误提示精度和团队协作容错上，实际更省力。
dart-sass 编译失败率远低于 less
Node 20+ 环境下，less 包偶发解析异常，比如 @import 路径错乱、变量穿透到不该出现的文件里；而 dart-sass 是纯 JS 实现，无原生模块编译环节，安装快、CI 流水线跑得稳。
常见现象：less-loader 在 Webpack 5 中报 ParseError: Unexpected token 却不标行号，排查要手动注释掉一半文件；sass 报错会直接指出 $spacing 在 _mixins.scss 第 12 行未定义，且显示调用链。
$ 变量默认块级作用域，@ 变量默认全局污染
Less 的 @spacing 声明后，只要没加 !important 或命名空间，后续任意文件里同名声明都会静默覆盖——两人同时开发 Button 和 Modal 组件，各自写 @spacing: 8px;，最终生效的是后编译的那个。
Sass 的 $spacing 在 @mixin 或嵌套规则内重新赋值，不会影响外层；想跨文件共享必须显式 @use 导入，否则直接报错。
-
@use "vars" as v;→ 强制命名空间隔离 -
@import已废弃，避免全局变量泄漏 - VS Code 对
.scss的 hover 提示、emmet 补全、重命名支持更准
& 引用父选择器行为更可预测
Less 的 &__icon 在多层嵌套时可能生成 .btn .btn__icon（意外空格），而非预期的 .btn__icon；Sass 的 &__icon 总是拼接为类名的一部分，只要父选择器是单一类名就可靠。
典型陷阱：.card { .header { &__title { ... } } } 在 Less 中可能漏掉 .card 前缀，Sass 不会。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
@use + @forward 模块化比 @import 更可控
Less 的 @import 是 inline 模式，所有变量、mixin 全局注入，顺序一错就覆盖；Sass 的 @use 默认不暴露内部变量，必须用 @forward 显式导出，组件样式可以封装成独立“包”。
例如：@use "button" with ($size: sm); 支持参数传入，Less 没有等价机制。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的点：不是语法难易，而是当新人接手老项目时，看到.btn(@size) 这种写法，会误以为是 CSS 类名；而 @include btn($size) 一眼就知道是逻辑调用。这种认知成本，在人员流动频繁的中小团队里，每天都在真实消耗。 
