Sass预处理器怎么用？，Sass和Less有什么区别？

Sass 上手并不难：用 npm 装一个 Dart Sass，在构建脚本里接一条编译命令，从变量和 @use 改起，一个下午就能跑通第一个样式模块；真正的门槛不在语法，而在团队规范。

下面按“它解决什么问题—怎么装—怎么选—怎么写—怎么在团队里落地”的顺序讲，涉及命令和配置的地方可以直接抄走。

原生 CSS 已经很强，Sass 还值得用吗

这几年 CSS 自己补上了自定义属性、嵌套、:is()、color-mix()，过去只有预处理器能干的事，浏览器慢慢都能干了。所以第一个问题很直接：还有必要上 Sass 吗。答案得分场景看。

• 01
  静态落地页、组件不到二十个的项目

  原生 CSS 加自定义属性完全够用，多引一层编译链反而增加维护成本。

• 02
  中后台系统、设计系统、多主题换肤

  Sass 的 mixin、函数、map、模块化能力能把重复代码压掉一大截，收益明显。

• 03
  一套设计令牌要供多个项目复用

  把色板、间距写成 Sass map，再统一输出成 CSS 变量，是实践中很常见的做法。

Sass 变量和 CSS 变量不是二选一

很多人卡在这个点上。记一句话就够：Sass 变量活到编译结束，用来算值；CSS 变量活在运行期，用来换主题。两者叠加使用才舒服。

$brand: (
  primary: #2f6fed,
  danger: #d9363e,
);

:root {
  @each $name, $color in $brand {
    --color-#{$name}: #{$color};
  }
}

业内专家指出，把主题色先收进 Sass map、再批量输出为自定义属性，既保留了构建期的拼写校验，也留住了运行时切换主题的能力。

Sass 安装配置教程：Windows 和 Mac 分别怎么做

先给结论：优先用 npm 装在项目里，而不是全局装。项目内安装会把版本锁进 package.json，同事拉下代码就能跑出一样的编译结果。

方式一：npm 安装 Dart Sass（推荐）

1. 在项目根目录执行 npm install -D sass。
2. 在 package.json 的 scripts 里加一条编译命令。
3. 执行 npm run sass 验证产物。

"scripts": {
  "sass": "sass src/styles/main.scss dist/styles/main.css --watch",
  "sass:build": "sass src/styles/main.scss dist/styles/main.css --style=compressed --no-source-map"
}

--watch 用于本地开发，改文件自动重编；上线走 sass:build，输出压缩版并省掉 sourcemap。--load-path 可以额外指定查找目录，公共样式库常靠它引入。

方式二：构建工具里直接接

Vite 只需装包，npm i -D sass 之后 .scss 文件就能直接 import，不用改配置。Webpack 需要 sass-loader 加 sass 两个包，并在 rules 里声明 test 规则。Rollup 用 rollup-plugin-sass 或交给 PostCSS 链路处理。

Windows 和 Mac 的差别主要在命令行环境

Windows 下如果报“无法加载文件，因为在此系统上禁止运行脚本”，是 PowerShell 执行策略的问题，改用 CMD 或把脚本换成 npx sass 调用即可。路径分隔符统一用正斜杠，能少踩一半坑。Mac 和 Linux 下命令基本一致，注意 Node 版本用 nvm 管好；Homebrew 也提供 Dart Sass，但版本切换不如 npm 顺手，团队环境还是统一走 npm 更稳。

Sass 和 Less 的区别，哪个更适合前端项目

这是搜索量一直很高的对比问题，直接上表格。

行业共识认为，新项目选 Sass 的比例更高，核心原因是模块系统和生态惯性。但反过来讲，如果手上是一套基于 Ant Design 3/4 的存量 Less 工程，为了“技术更新”去重写一遍样式，投入产出比并不好看，先把手头的规范做扎实更实际。

写出可维护的 Sass：几条必须守住的规矩

嵌套别超过三层

嵌套是 Sass 最好用也最容易失控的地方。超过三层，选择器权重就会一路飙升，后面想覆盖只能加 !important。约定是：嵌套层数控制在三层以内，组件内部用 BEM 命名把层级写在类名上。

/* 不推荐 */
.card { .body { .title { span { color: red; } } } }

/* 推荐 */
.card__title-text { color: red; }

@use 和 @import 有什么区别，为什么新项目别再写 @import

老代码里满地 @import，但官方已明确会在后续大版本中移除它，新项目没有理由再用。差别就三条：

• 01
  加载次数

  @import 每个文件引一次就编译一次，重复引入会重复输出；@use 只加载一次。

• 02
  作用域

  @import 把变量和 mixin 摊进全局，容易撞名；@use 默认带文件名命名空间。

• 03
  可追踪性

  @use 的依赖关系一目了然，改一个变量能顺着命名空间找到出处。

/* _tokens.scss */
$radius: 6px;
$space: 8px;

/* main.scss */
@use 'tokens';

.btn {
  border-radius: tokens.$radius;
  padding: tokens.$space;
}

需要把子模块对外转出时用 @forward，常见于 abstracts/_index.scss 这类汇总文件，外部只需引一个入口。想改命名空间就写 @use 'tokens' as t;，想直接摊平可用 as *，但摊平会丢掉隔离优势，慎用。

Sass mixin 怎么用才不滥用

mixin 适合“一段带参数的样式集合”，典型场景是文本截断、清除浮动、响应式断点。判断标准很简单：能想清楚它会输出多少行 CSS，就用；想不清楚，就别封装。

@mixin truncate($lines: 1) {
  @if $lines == 1 {
    overflow: hidden;
    white-space: nowrap;
    text-overflow: ellipsis;
  } @else {
    display: -webkit-box;
    -webkit-line-clamp: $lines;
    -webkit-box-orient: vertical;
    overflow: hidden;
  }
}

@mixin bp($min) {
  @media (min-width: $min) {
    @content;
  }
}

.title { @include truncate(2); }
.sidebar { @include bp(1024px) { display: block; } }

反模式提醒

见过把整个页面布局塞进一个 mixin 的写法，调用一次输出两百多行，改一个间距要翻三处文件。mixin 只收“原子级、可复用、参数化”的东西，整块布局老老实实写选择器。

函数、map 与循环

内置模块要显式引入，除法用 math.div 而不是斜杠，颜色调整用 color.scale 或 color.adjust。写间距体系时用 map 加 @each 批量生成工具类，比手写十几个类名可靠得多。

@use 'sass:map';
@use 'sass:math';

$spacers: (1: 4px, 2: 8px, 3: 16px, 4: 24px);

@each $key, $val in $spacers {
  .mt-#{$key} { margin-top: $val; }
}

团队落地：目录结构与工具链

小项目一个文件也能跑，但一旦超过五个开发者，目录约定就必须提前定。业界常用的 7-1 模式可以简化成五层：abstracts（变量、mixin、函数，不产出 CSS）、base（重置、排版）、layout（栅格、容器）、components（按钮、卡片）、pages（页面级覆盖）。

配套加两件事：一是 stylelint 加 stylelint-scss 插件，把嵌套深度、命名规则、禁用 @import 写成规则，机器管比人盯靠谱；二是产出 sourcemap 并在构建产物里保留，线上排查样式来源时省时间。据近年来 State of CSS 开发者调查，Sass 在 CSS 预处理器中的使用率长期位居前列，这也意味着遇到问题时能找到的中文资料和社区方案足够多。

Sass 使用中的常见疑问解答

Sass 使用要花钱吗，团队规模大了会不会有授权成本

不会。Dart Sass 以 MIT 协议开源，商用、闭源、团队多少人都不影响，成本只体现在引入编译环节多出来的构建时间和一点点学习曲线。真正花钱的是人力，所以规范比工具选型更值得投入。

用了 Sass 还需要 PostCSS 和 autoprefixer 吗

需要，两者解决的问题不重叠。Sass 负责变量、嵌套、函数、模块这些构建期能力；PostCSS 负责加浏览器前缀、语法降级、压缩优化。常见链路是先跑 Sass 生成 CSS，再交给 PostCSS 处理，配置里注意插件顺序即可。

老项目从 @import 迁移到 @use 有哪些坑

主要三个：全局变量在 @use 下不再自动可见，每个文件要显式引入；不同文件里的同名变量会产生命名空间冲突；原来靠 @import 隐式传递的 mixin 需要补上引用。稳妥做法是按目录分批迁，先迁变量与 mixin 层，再迁组件层，每迁一批跑一次视觉回归比对，避免样式无声失效。