新项目优先选scss，因vue/react脚手架默认支持；老项目或需浏览器端编译时选less，更轻量易上手。scss变量用$声明、作用域严格、支持!global和!default，less用@声明、默认词法作用域、静默覆盖易埋坑。
Sass 和 Less 在实际项目里选哪个，不取决于“谁更先进”，而取决于你用的构建工具链、团队习惯、以及是否要兼容老项目。 直接说结论：新项目用 SCSS（即 Sass 的 .scss 语法），已有 Vue/React 脚手架默认支持；老项目或需浏览器端实时编译时，Less 更轻量、上手快。
SCSS 和 Less 的变量声明与作用域差异在哪
变量写法是第一眼就能区分两者的标志，但容易忽略的是作用域行为：
-
$color: #3498db（SCSS）和@color: #3498db（Less）都支持局部/全局作用域，但 SCSS 中未用!global显式声明的变量，在嵌套规则内修改不会影响外层；Less 默认按词法作用域查找，更接近 JS 的let行为 - SCSS 的
map-get($theme, "primary")是强类型映射访问，Less 没有原生 map，得靠extract()或插件模拟，写起来更啰嗦 - 变量重名时，SCSS 会报错（除非加
!default），Less 则静默覆盖——这在多人协作中容易埋坑
为什么 Mixin 在 SCSS 里比 Less 更灵活
两者都用 @mixin / @include（Less）和 @mixin / @include（SCSS），但参数处理能力差一截：
- SCSS 支持命名参数调用：
@include border-radius($radius: 4px, $prefix: webkit)；Less 只能靠位置或手动解构@arguments - SCSS 允许参数默认值 + 可变参数（
$rest...），Less 的...仅限于传递给其他 mixin，不能做逻辑判断 - SCSS 的
@content指令可注入任意样式块，实现“带样式的容器”（比如媒体查询 wrapper），Less 没有等价机制，得靠多层 mixin 套娃
编译阶段出错时，SCSS 和 Less 的错误提示谁更友好
不是“谁更好”，而是“错在哪一层”决定了调试成本：
- SCSS 编译错误（如
Undefined variable "$xxx"）通常定位到具体行+列，且 Webpack 的sass-loader会把源码映射回.scss文件；Less 的variable @xxx is undefined提示也准，但若用了less-plugin-functions等第三方插件，堆栈可能断在 JS 层 - SCSS 对语法容错极低：少个
;、缩进错一级、括号不匹配，直接中断编译；Less 对空格/换行更宽容，适合边写边改，但也意味着某些低级错误可能潜伏到运行时才暴露（比如颜色函数拼错成darkenr()） - 两者都不支持运行时热替换 CSS 变量值——别指望像 JS 那样改个
$color就实时预览，必须触发完整重编译
Vue 或 Create React App 里引入预处理器的实际约束
脚手架封装了底层，但掩盖了关键限制：
- Vue CLI 默认只配了
sass-loader，想用 Less 得额外装less和less-loader，且vue.config.js里要显式配置additionalData才能全局注入变量；Create React App 5+ 开始原生支持 SCSS，但对 Less 仍需craco或 eject -
@import行为不同：SCSS 的@use（推荐）和@forward是模块化方案，避免全局污染；Less 的@import默认仍是拼接式导入，容易重复编译同一份变量文件，引发 CSS 体积膨胀 - PostCSS 插件（如
autoprefixer）通常在预处理器之后执行，所以SCSS里的flex不会自动补-webkit-flex，得确保 PostCSS 配置生效——这点常被忽略，导致样式在旧 iOS 上失效
真正卡住人的从来不是语法差异，而是当一个 @import "vars" 在 SCSS 里被写了三次、在 Less 里被 modifyVars 覆盖两次，又混着 Webpack 的 resolve.alias 时，你根本分不清最终生效的是哪个 $primary-color。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
