优先选 sass（.scss），因其错误提示精准、作用域严格、模块化能力强、ci/cd 稳定；less 仅适用于需浏览器端编译或维护老项目的特定场景。
选 Sass（.scss），除非你明确需要 Less 的某个具体特性，比如浏览器端实时编译、或正在维护一个强依赖 @import 全局拼接的老项目。
编译失败时能不能快速定位到问题源头
错误提示质量直接决定你花 2 分钟还是 20 分钟修一个变量名拼错。Sass（Dart Sass）报错带精确行号+列号+上下文代码片段，例如：Error: Undefined variable "$primary-color" 后面会跟上“used in _button.scss line 12, defined in _vars.scss”，还能展开变量赋值链；Less 常只报 ParseError: Unexpected token 或 NameError，不指明来源文件，尤其在多层 @import 时得手动翻查。
- Sass 错误能跳转到 VS Code 中具体字符位置；Less 多数时候只能定位到某一行，还得自己扫
- Less 中写错
&:hover::before可能静默编译出无效 CSS；Sass 会立刻报Invalid CSS after "&:" - 如果你用 CI/CD 跑构建，Sass 在 GitHub Actions 等轻量 runner 上更稳，Less 编译大文件（>2000 行）偶尔 OOM 或超时
变量和 mixin 是不是真能“局部复用”
变量不是写完就能用的字符串替换——它们的作用域规则决定了改一个值会不会意外影响整个系统。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- Sass 的
$var: value !default显式表达“仅当未定义时才生效”，配合@use "vars" as v实现模块级作用域，v.$color必须显式命名空间调用 - Less 的
@var: value是全局惰性覆盖：后声明的同名变量无条件覆盖前声明，哪怕跨文件@import，容易导致主题色被某个组件样式悄悄改掉 - Sass 的
@mixin+@include强制参数校验，IDE 自动补全好；Less 的.mixin()写法像类选择器，新人易误写成.mixin { }导致编译失败，且不支持命名参数
项目里要不要写循环、条件、函数逻辑
如果只是换几个颜色、套几层嵌套，两者都够用；但一旦涉及动态生成断点、栅格类、图标状态组合，能力差距就暴露了。
- Sass 原生支持
@each $key, $val in $breakpoints和@if / @else，可嵌套、可返回值，@function能封装复杂逻辑 - Less 的循环只能靠递归
mixin模拟，代码冗长，深度大了容易栈溢出；when守卫只用于mixin匹配，不能在普通规则中做分支 - 颜色函数行为也不同：
darken($color, 10%)（Sass 是 HSL 模式）和darken(@color, 10%)（Less 是 HSB 模式）输出色值可能不一致，设计还原时容易出偏差
真正难的不是语法本身，而是团队协作中变量污染、mixin 调用不统一、错误排查靠猜这些隐性成本。Sass 的 @use、严格作用域、精准报错和主流脚手架（Vite/Next.js/CRA）默认集成，让这些成本大幅降低。Less 的轻量和语法亲和力，在小型项目或遗留系统里仍有价值，但别低估它在中大型项目里积累技术债的速度。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
