直接写CSS易失控因缺乏变量、嵌套、mixin等能力，导致重复硬编码和维护困难；Sass/Less通过收口重复逻辑提升可维护性，但需注意语法差异、嵌套层级、数学模式及构建配置。
为什么直接写 CSS 容易失控，而 Sass/Less 能缓解？
纯 CSS 缺乏变量、嵌套、混合（mixin）、函数等能力，导致相同颜色、间距、响应式断点反复硬编码。一旦设计系统调整，就得全局搜索替换，极易漏改或误改。color: #333 出现 87 次？改一个主题色就得手动点开每个文件——这不是开发，是考古。
预处理器不是银弹，但能把你从「复制粘贴 CSS 块」的循环里拉出来。关键不在语法炫技，而在把重复逻辑收口到可维护的位置。
Sass 和 Less 的核心差异：变量和嵌套怎么写才不踩坑？
两者都支持变量和嵌套，但语法细节影响协作和迁移成本：
-
$primary-color: #007bff（Sass） vs@primary-color: #007bff（Less）——符号不同，混用项目会报错 - 嵌套层级别超过 3 层：
.header { .nav { .item { &:hover { ... } } } }生成的 CSS 选择器过长，影响性能且难以覆盖；建议用 BEM 类名替代深层嵌套 - Less 默认不启用严格数学模式，
width: 10px + 5会被当成字符串拼接；Sass 默认按数值计算，更符合直觉
如何在真实项目中落地 mixin 和 function？
别一上来就写 20 个 @mixin clearfix，先解决高频痛点：
立即学习“前端免费学习笔记（深入）”；
- 响应式工具：
@mixin media-breakpoint-up($name) { @media (min-width: map-get($grid-breakpoints, $name)) { @content; } }（Sass）比手写@media (min-width: 768px)更安全，断点值集中管理 - 渐变兼容处理：Less 的
.bg-gradient(@color1, @color2) { background: @color1; background: linear-gradient(to right, @color1, @color2); }避免每次重复写 fallback - 慎用复杂 function：比如用 Sass 写颜色明暗调节
lighten($color, 10%)很方便，但若团队不熟悉颜色模型，反而增加理解成本
Webpack/Vite 中引入 Sass/Less 的最小配置要点
不是装了 sass 或 less 包就能用，编译链路必须打通：
- Vite 项目：默认支持
.scss和.less，但需安装对应依赖：npm install -D sass或npm install -D less；缺一个包，@import就静默失败 - Webpack 项目：确认
style-loader+css-loader+sass-loader（或less-loader）顺序正确；sass-loader版本 > 12 时，implementation必须显式指定为require('sass')，否则报TypeError: this.getOptions is not a function - 全局变量注入（如统一颜色变量）：Vite 中用
css.preprocessorOptions.scss.additionalData，Webpack 中用sass-loader的additionalData选项；路径写错会导致所有组件里$primary-color报Undefined variable
真正卡住人的往往不是语法，而是编译器找不到你写的 _variables.scss，或者 loader 把 @import 当成 CSS 原生 import 处理了。
