做前端的人大概都经历过这么一幕项目要搭样式方案团队模板里可能写着.scss也可能写着.less老同事随口一句“就用这个吧”于是你稀里糊涂跟了好几年。直到某天面试官问“Sass 和 Less 到底怎么选”你才发现自己其实从来没认真想过这个问题。这篇就围绕 Sass 和 Less 的核心差异、编译与配置方式、生态影响以及实际工程里的选型逻辑把这事聊透。这篇文章适合三类人刚入门、正在纠结拿哪个写简历被老项目绑在某个预处理器上、想评估迁移成本的人还有带项目、需要给团队定统一方案的前端负责人。我会尽量把话说直白变量、嵌套、混合、函数、循环这些核心能力挨个过一遍再配合真实工程里的编译配置和踩坑记录方便你看完就能直接拿主意。1. 先搞清楚Sass 和 Less 到底在解决什么问题CSS 本身很简单没有变量、没有函数、没有循环写长了就是一堆重复的色值、间距和选择器。你改一个主题色得全局搜索替换十几处你写弹窗阴影、按钮悬浮态同一个“嵌套关系”要反复把父选择器抄一遍。Sass 和 Less 这类 CSS 预处理器本质上就是把 CSS“伪编程化”——让你能像写代码一样写样式。拿生活类比CSS 相当于“手写记录”你每写一条都是一次性固定内容Sass 和 Less 相当于给这套记录系统配了模板、计算器和批注工具。Sass 起步早功能野心更大官方定位是“具备编程语言能力的样式扩展”Less 起步稍晚更强调“增强 CSS 而非取代它”它要求你原先怎么写 CSS现在基本还能怎么写只在小部分地方加一层语法糖。很多人还会被 Sass 的旧语法绕晕。Sass 有两种写法一种是老式缩进语法叫 Sass长得像 Ruby/Python靠缩进表示层级现在基本没人用了另一种是刮号括号语法 SCSS支持.scss扩展名写法更接近 CSS是目前整个生态的主流。Less 只有一种写法和 CSS 的兼容程度最高——一个.less文件去掉变量定义、混合宏这些新增语法后几乎就是合法 CSS。这两个工具的核心解决路径是重合的变量、嵌套、混合宏、继承、运算、函数、作用域、模块化。你在任意一个里面养成“抽变量、拆模块、写混合宏”的习惯另一个上手也不会超过一个下午。真正拉开差距的是细节深度、编译工具链和生态绑定这也是后面几个章节要重点说的。2. 五分钟语法对比变量、嵌套、混合、继承全面PK2.1 变量定义与访问变量是最基础的一环Sass 用$开头Less 用开头。看起来只是符号差异实际使用里有重要区别Less 的变量是“懒加载”的你可以在变量定义之前引用它Sass 更严格默认从作用域和顺序角度更接近普通编程语言。// SCSS $primary: #1890ff; $primary-dark: darken($primary, 10%); .button { color: $primary; }// Less primary: #1890ff; primary-dark: darken(primary, 10%); .button { color: primary; }两条都用最直观的“定义后引用”。但 Less 还支持“把变量当属性名和选择器名的一部分”和“变量延迟加载”这给了一些很花的玩法比如动态类名side: left; // 编译后 .border-left .radius-{side} { border-{side}-radius: 2px; }这种字符串插值玩法 Sass 也有只是写法不同。变量差异本身对选型影响不大真正容易踩坑的是 scopeSass 把作用域这事搞得对手感更精细而 Less 自带全局搜索、延迟加载的语义在某些复杂场景下会带来“变量到底被谁覆盖了”的困惑。2.2 嵌套写法和父选择器嵌套语法两边几乎同构都是用花括号包层级关系并用指向当前父选择器。绝大多数开发者选 Sass 或 Less先感受到的就是这里——以前写BEM全得手敲有了嵌套后至少能少一半体力活。.card { padding: 16px; .title { font-size: 16px; } .selected { border-color: $primary; } :hover { box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15); } }这里要表扬 Sass 一个细节它提供了at-root指令可以突破嵌套层级。比如命名空间式的设计系统里你想让--variant不挂在父级下面直接输出成顶层类at-root就是干这事的。Less 没有直接的等价物只能靠你手动把选择器提出来手段上笨一点。嵌套的另一面是“滥用”。无论是 Sass 还是 Less建议嵌套不要超过三层否则选择器会膨胀成.block__element--modifier .child .grandson这种怪物调试时在浏览器里连自己都找不到来源。这是我在代码评审里规定过的一条铁律。2.3 混合宏复用的两种哲学混合宏Mixin是两边都很重要的复用手段但哲学不同。Sass 的mixin更像“函数模板”允许传参、带默认值、甚至用content往里面塞一段样式块Less 的混合宏就是一个带括号的类样式块可以直接“复制粘贴”到目标位置连编译器的设计理念里都强调“点一下就用”。// Sass mixin button($bg: #fff) { display: inline-flex; align-items: center; background: $bg; :hover { background: darken($bg, 5%); } } .btn-a { include button(#f5222d); } .btn-b { include button(); }// Less .button(bg: #fff) { display: inline-flex; align-items: center; background: bg; :hover { background: darken(bg, 5%); } } .btn-a { .button(#f5222d); }看代码会觉得只是语法换皮但写多了之后会发现 Sass 的 Mixin 体系更强。尤其是content这种“前后挂样式块”的写法非常适合抽离媒体查询、响应式断点这类有“包外壳”需求的逻辑mixin mobile { media (max-width: 767px) { content; } } .foo { include mobile { display: none; } }Less 没有这种能力虽然多数场景不致命但当你需要做复杂主题化的组件抽象时会明显感到 Less 的混合宏更“呆”一些。2.4 继承、占位符与模块化Sass 提供了extend和占位符选择器%这两者组合起来能实现“只定义一次、多处共享选择器规则且最终编译时把选择器合并成一组”的优化效果。Less 的:extend()也可以做到类似逻辑但少一个“占位符”的抽象抽公共类时更依赖你维护实体类名。// Sass 占位符不会出现在 CSS 里只被 extend 使用 %reset-button { border: 0; background: none; padding: 0; } .btn-c { extend %reset-button; } .other { extend %reset-button; }编译结果是.btn-c, .other { border: 0; background: none; padding: 0; }。这套机制能显著减少重复样式的体积Less 的:extend()能力有限团队如果特别在意输出 CSS 的体积和规则合并效率优先选 Sass 很合理。模块化是另一个容易被忽略的差异点。老版本 Sass 的import和 Less 的import差不多都是“文本合并”。但现代 Sass 已经用use和forward取代了import每个文件有自己的命名空间引入变量时要写namespace.$variable。Less 的官方姿势还是import没有严格的模块作用域这一层这也是 Less 被称为“更贴近 CSS”的另一面。3. 编译那点事Sass 编译与 Less 配置的工程化实操3.1 编译器实现和安装方式用法差异再大最终都得把.scss/.less文件编译成浏览器认识的 CSS。这一步是理解选型的关键Sass 已经换过两代编译器Less 则一直保持相对单一的实现。Sass 最早绑定 Ruby性能一般后来 LibSass 用 C 实现性能起飞还衍生出node-sass这种绑定包。但 LibSass 的开发跟不上官方 Sass 的脚步官方已经正式宣布弃坑当前标准是 Dart Sass——过程就是“用 Dart 语言重新实现一份 Sass 编译器语法和功能更新最快且能编译成纯 JavScript 版本给 Node 工程直接调用”。你现在在 Node 项目里npm install -D sass拿到的就是 Dart Sass。基本命令很简单npx sass src/styles/app.scss dist/styles/app.cssLess 的官方实现一直基于 Node你在工程里npm install -D less拿到的是带lessc这个二进制入口的 JS 编译器npx lessc src/styles/app.less dist/styles/app.css3.2 在 Vite 和 webpack 里的接入配置真实项目大多不会手动执行命令行而是交给构建工具。Vite 这边接入两个预处理器都很轻松官方甚至不要求你在配置文件里做太多事只要装好包Vite 会自动识别.scss和.less文件的后缀。但如果你想做一些自定义还是得改vite.config.js// vite.config.js import { defineConfig } from vite; export default defineConfig({ css: { preprocessorOptions: { less: { javascriptEnabled: true, modifyVars: { primary-color: #1DA57A, }, }, scss: { additionalData: use /styles/variables.scss as *;, api: modern-compiler, }, }, }, });上面这段有讲究。Less 的modifyVars是配置主题的核心入口我做后台项目时经常用它覆盖 UI 组件库的主题色不需要动源码Sass 的additionalData会把变量文件预注入到每个编译单元但如果你用的是旧版import函数会带来“每个 scss 都重复注入一份变量”的冗余问题所以新版推荐用use as *来带命名空间。api: modern-compiler是 Vite 5.4 之后配合新 Sass API 的选项不写会走 legacy API兼容性后面再讲。webpack 里对应的是sass-loader和less-loader配置大同小异如果遇到 Less 想修改变量、Sass 想传includePaths的场景loader 的options里都能找到对应字段。3.3 编译参数和源映射sourcemap无论是sass还是lessc编译都支持sourceMap选项。上线前你当然希望 CSS 体积小、压缩到位调试时你却需要“点浏览器样式跳到源码文件”的体验。生产环境我会设sourceMap: false和压缩输出开发环境则把sourceMap: true打开npx sass src/styles/app.scss dist/styles/app.css --stylecompressed --source-map npx lessc src/styles/app.less dist/styles/app.css --source-map --clean-cssSass 还有--styleexpanded、--stylecompressed两种常用输出格式。Less 默认输出就是“素颜 CSS”不加插件不会自动压缩clean-css插件或压缩构建链通常交给 Webpack/Vite 的配套工具去做。注意如果你在用很老版本的node-sassnpm install阶段经常出现二进制下载失败的报错。node-sass 的生命周期已经宣告结束新项目不要再新建node-sass依赖直接平迁到sass包语法兼容度远比你想象得高。3.4 编译链的调试体验我在实际体验里感受最强烈的一点Sass 的报错信息往往更“聪明”它会告诉你哪一行、哪个 mixin、什么条件下出问题Less 的报错相对朴素尤其是复杂嵌套和计算混在一起时经常只给一个“Expected } on line X”的笼统提示得靠人工猜。所以 intuition 上Sass 更适合大型团队它的编译器把“错误定位和模块解析”当一等公民对待Less 更适合小团队和个人项目配置更少、链路更短、心智负担更低。这个朴素的“大项目选 Sass轻项目选 Less”的判断并非空穴来风。4. 深层能力差异函数库、模块系统和生态圈4.1 内置函数和运算能力一提到“预处理器”很多人第一反应是变量和嵌套但真正决定能不能写复杂样式逻辑的是能不能算、能不能查、能不能循环。Sass 内置函数非常完整色值函数darken、lighten、mix、rgba、列表函数nth、index、join、Map 函数map-get、map-merge、map-keys、数值函数math.div、math.round、数学包足以支撑设计系统里的“调色板自动生成”。你再抽象一个“根据主色算出悬浮色、边框色、阴影色”的函数Sass 完全做得到。// Sass 生成按钮色板 function make-button-colors($base) { return ( bg: $base, hover: darken($base, 5%), active: darken($base, 10%), border: rgba($base, 0.5), ); } .btn { background: map-get(make-button-colors(#1890ff), bg); }\style 上 Less 的内置函数少很多色值函数darken、lighten、类型函数iscolor、isnumber也有一些但列表操作和 Map 结构基本要靠“变量分组 JavaScript 表达式插件”去模拟没有 Sass 那种“原生数据结构”的顺滑感。4.2 条件与循环Sass 完整支持if/else、for、each、while你基本是拿“循环生成工具样式”的思路写 CSS一个each可以把 pr-4、pl-4、m-4、mt-4 这种工具类批量生成这在做团队内部设计系统时非常高效。Less 没有原生循环想复用只能靠“递归调用混合宏”绕路。比如生成一个网格栅格的系列Sass 写for很直白Less 就得定义一个不断调用自己的 Mixin配合when条件来模拟循环的退出。两者都能实现但 Sass 更接近真正的编程语言。4.3 模块系统和第三方生态生态其实是很多人忽略的决定因素。Sass 和 Less 的意义不只是自己写而是你要接的第三方库是用什么写的。Bootstrap 从第 4 版开始全面 Sass 化默认模板、主题变量、自定义构建都是基于 Sass。Element UI / Element Plus 这套流行的 Vue 组件库从上到下都是 Sass 变量体系。Ant Design 从上到下都是 Less它的主题定制依赖modifyVars打 Less 包的变量所以用 antd 时你基本被“绑定”在 Less 链条上。还有很多老牌第三方库例如部分 jQuery 时代的 UI 套件仍保留 Less 源文件改动样式时得跟着它的编译链走。如果你的项目里已经捆绑了某个大型组件库直接沿用它的预处理器是成本最低的方案。强行“换一条赛道”意味着你每改一次主题变量都要额外做一层变量映射往往得不偿失。Sass 的模块系统天然适合大型项目use通过命名空间避免变量名冲突forward可以建立“入口文件”将一堆小组件变量转发出去。Less 的import是传统文本导入只要跨文件变量重名就会在编译阶段被覆盖久而久之你看到的是“各种变量在全局里乱撞”排查比写代码还耗时。再提一个性能角度Dart Sass 的编译速度在大项目里比 Less 稍慢尤其是大量使用高级函数和 Map 时每改一个变量整个链路的重新求值会比较吃 CPU。Less 编译普遍快适合频繁改动的小项目。这个差异在 5000 行以内的样式工程里可以忽略不计但到了几万行且配置复杂的设计系统里你会明显感觉到。总的来说功能边界上 Sass 的“上限”明显更高Less 的“下限”更轻松好靠近。选型时真正要问自己的不是“谁语法更简单”而是“我的项目有没有复杂的样式逻辑要写”。5. 选型决策5分钟判断你的项目该用哪个5.1 四个最快判断维度我把选型逻辑压缩成四个问题按顺序回答基本能拿定主意。第一问项目依赖的主流 UI 组件库偏向哪边如果你用了 Ant Design 系列Less 基本是“既定路线”如果你用了 Element Plus、BootstrapSass 通常是税如果你是自己封装组件库可以自由选。第二问项目样式有没有大量的复杂度需要处理例如动态主题、多个肤色变量、复杂的 breakpoint 组合、工具类自动生成。有这些诉求Sass 更合适纯静态页面、以还原设计稿为主Less 更轻更快。第三问团队成员更熟悉哪套语法这个因素放在第三位不是为了敷衍而是工程决策里“团队可持续维护”比“技术上限”更真实。比起硬切 Sass让一个写了两年 Less 的人快速产出学习成本低得多。第四问你受得了哪种构建链Less 一路用 JS链条短、props 简单Sass 有 Node 和 Dart 两套二进制的区别不同版本的sass-loader和Vite api选择需要更多精力维护。如果团队没有专人维护前端工程化配置选 Less 的稳定性更省心。5.2 常见场景的选型结论场景一基于 Vue 3 Element Plus 的“中后台管理系统”。建议选 Sass。因为 Element Plus 的样式本身就是 Sass 写的你跟着它的模式组织变量后面做私有主题更顺。即便团队一点都不懂 Sass也只学最常用的变量、嵌套、上下文归组不出三天就能赶上。场景二基于 React Ant Design 的“企业级后台”。建议选 Less。Ant Design 的modifyVars机制是用 Less 实现的换 Sass 意味着每次升级都有一层额外的转换成本。这里不要为了“技术好听”去反着来。场景三纯移动端 H5 落地页、活动页样式总量小设计稿固定。Less 就够了。这部分页面几乎用不到循环和函数用 Sass 纯属给编译链添复杂度Less 的轻量化配置和快速构建更占优势。场景四自研组件库 / 设计系统 / 多主题项目。建议选 Sass。主题令牌、Map 映射、循环生成工具类这些能力Sass 的抽象能力和维护成本控制明显更好。真实设计系统里变量成千上万Less 的“全局导入”模式真的会积累技术债。我还想多提一个维度以后招人的“通用能力”问题。假设你现在招一个 5 年前端简历里大概率写的是 Sass毕竟 Bootstrap 和其他主流开源库的影响力在Less 的技能更多是 antd 生态带出来的。如果团队长期需要两手都能抓的人优先 Sass 会更容易找到经验和社区方案。5.3 新项目还没确定给两点实用建议如果看完表格还是纠结我建议新项目覆默认“优先 Sass除非有强理由”。这么做不是因为 Less 不好而是 Sass 的生态文档、社区提问、坑位总结都更丰富遇到问题搜答案的成功率更高Less 在某些特殊场景的搜题体验相对稀薄出错时容易陷入孤独调试。但你如果整个项目已经绑定了 antd 或者老代码大量是 Less就别折腾了。迁移到 Sass 不是“改个后缀那么简单”变量符号、函数写法、模块导入规则全得改一个几千行样式的项目迁起来至少是“一两天纯手工活”出来的效果并不会让产品体验更好没有消费者看到。技术选型首先要服务“交付稳定性”其次才是“团队的爽度”。6. 常见问题和排查技巧实录6.1 Sass 编译遇阻先看这六个位置第一老项目在node-sass上反复npm install失败。这个包已经进入维护末期安装频繁触发二进制下载问题。能做的只有两条路要么锁版本、造缓存、闭网安装要么趁早切sass切之前把node-sass和sass-loader配套升级到兼容版本。第二除法运算报错或结果不对。Dart Sass 较新版本把/从“除法”改成了普通分隔符真正的除法得用math.div($a, $b)或者确保写在calc表达式里面。老代码写成width: 100% / 3;的都会“静默出问题”排查时很隐蔽。第三import用惯了突然报“Sass import rules are deprecated and will be removed”。Local 明确表示清理旧的import体系新版建议改用use。如果项目依赖大量第三方旧版库它们内部还在用import你可以先调整自己代码用use再排查第三方的兼容情况。第四darken函数报“deprecated”。Sass 维护者希望色值函数走color.adjust这套新 API。语法不熟导致改造量大老代码可以先按住不动新代码逐步适应新 API 即可。第五变量文件被每个组件各自import一次导致编译产物里重复出现变量定义。改用use和使用命名空间后解决。第六源映射失效浏览器里断点跳不到.scss文件。多半是构建器的devtool和css.sourcemap配置互相打架核查 webpack/Vite 两处配置是否同时打开。6.2 Less 配置踩坑实录Less 最常见的问题是“变量被预料之外地覆盖”。因为 Less 支持“懒加载”变量的取值时机是基于“最后赋值”而不是“当前作用域定义的位置”。你在文件顶部引用一个变量结果后面文件一import进来把变量改了前面已经在用的样式突然就变色。建议给项目约定变量文件唯一并且永远优先导入不要在业务样式里改全局变量。第二个高频问题是 Less 的javascriptEnabled开关。新版本 Less 默认不允许在 Less 文件里执行 JavaScript 表达式但一些老第三方包会这么写构建直接报 “Inline JavaScript is not enabled”。很多时候你会手滑在 Vite 配置里把javascriptEnabled设成true安全上其实不太推荐让编译链支持任意 JS 执行等于给样式注入了执行面。如果只是为了兼容某个旧库可以全局搜一下具体哪些节点需要 JS改成函数思路或者锁定对应版本。第三个问题是 Less 的深选择器写法。做 Vue 组件样式隔离时需要穿透到子组件内部Less 老库喜欢用/deep/Sass 老库流行::v-deep但双方在新版本都推荐用:deep()统一写法。如果一个项目里混用了 Less 和 Sass这两个历史写法会把排查逼疯。我曾经在同一个项目里看到/deep/和::v-deep混用完全相同的目标选择器只有一条生效找了一下午。第四个问题跟“计算不换行”有关。Less 里的 CSS 压缩校对和 calc 表达式有冲突比如calc(100% - 20px)中间的空格一旦被压缩掉表达式就废了。你需要在关键字符位置维护空空格组合或者在配置里告诉压缩器不要把calc里的空格去掉。6.3 混合使用和迁移的经验速查如果项目里同时存在.scss和.less文件请务必建立一条铁律新代码统一走一种预处理器另一种只做存量维护。混合使用会带来变量隔离问题、构建配置复杂化、以及团队认知负担三重成本。我见过一个项目里 Sass 变量和 Less 变量因为名字冲突导致颜色“漂移”的惨案两个文件各自定义同名变量业务代码不加统一前缀最后重构时只能靠 git blame 追责。迁移的路径建议按“先底层后业务”推进先把变量、Mixins、函数这些共享层迁过去让业务文件还能用旧的语法最后一步再重写业务文件。这样中间状态不会出现“一半变量能解析、一半直接编译失败”的断档风险更可控。下面是几个比较值得存下来的排查对照症状可能原因处理方式Sass 报 division 结果不对新版把/当分隔符改用math.div($a, $b)编译产物里出现重复变量定义每个文件都import了变量文件改用use 命名空间Less 变量莫名被覆盖多个文件后导入同名变量统一变量文件并约定导入顺序Less 里写 JS 表达式报错javascriptEnabled未开或版本限制尽量不用内联 JS或针对旧库单独兼容深选择器不生效混用/deep/和::v-deep统一改用:deep()浏览器看不到源码映射devtool 和 css sourcemap 不一致统一改成 development 模式全开Vite 下 Sass 构建报 legacy APIapi未设modern-compiler配置api: modern-compiler7. 最后再分享一点个人经验做前端这些年我不太认同“Less 已经被 Sass 淘汰”这种说法。真实生态里Less 因为它绑定 antd、绑定某些老牌 UI 框架仍然拥有大量存量项目。选型本质上是“生态匹配”和“团队舒适度”的权衡。如果让我给我的新项目定一个“默认值”我会优先选 Sass函数、模块化、工具生态的现代程度确实领先长期维护更省心但碰到项目压根没有复杂逻辑、只求快速交付Less 的轻量、精简和“不给你加戏”也能让人很舒服。还有一点发自内心的建议不管最后选谁真正决定工程质量的是你有没有把“抽变量、拆模块、写 Mixin”这套纪律落实下去。没有纪律Sass 会让你的样式文件变成一个“看起来能编程实际上全是全局飞线”的巨型泥潭没有纪律Less 也会让你的变量文件出现十几个同名变量互相打架。预处理器的能力上限摆在那里用得好是工具用不好是负担这一点比“Sass 还是 Less”本身重要得多。