提升Sass编译速度：从LibSass迁移至Dart Sass指南

如果你仍在使用 node-sass 编译样式，可能正在承受不必要的性能损耗与兼容性风险。一个明确的建议是：替换 node-sass，改用 sass（Dart Sass），这通常是提升编译速度最直接、最有效的方法。 实际测试表明，冷启动速度可提升30%至50%，增量编译的优势则更加显著。

为何必须放弃 node-sass？

核心原因在于，node-sass 所依赖的 LibSass 编译器已于2020年10月正式停止维护。这意味着，你遇到的各种棘手问题，其根源很可能都指向它：

• 安装困难：在 Node 16 及更高版本环境中，执行 npm install node-sass 经常失败，因为它需要依赖 Python 2.7 和 node-gyp 进行本地编译。
• 流水线中断：在 CI/CD 流程中，因二进制文件下载超时导致构建失败的情况时有发生。
• 语法不兼容：当你尝试使用现代的 @use 模块语法时，可能会遇到 Invalid CSS after "@use" 错误——node-sass 并不支持该语法。
• 版本链断裂：升级 Webpack 或 sass-loader 后构建突然崩溃，排查后发现，新版的 sass-loader@12 要求使用 sass 包，已不再兼容 node-sass。

迁移三步走，顺序是关键

从 node-sass 迁移到 Dart Sass 的过程并不复杂，但必须严格按照顺序执行，跳过任何一步都可能引发静默错误或导致回退到旧行为。

1. 彻底卸载旧包：首先运行 npm uninstall node-sass。这一步是为了避免残留的包被 loader 错误地回退使用。
2. 安装新包：接着运行 npm install sass sass-loader@latest --sa ve-dev。注意，sass-loader@12 及以上版本才能完整支持 @use 语法和模块缓存机制。
3. 显式指定实现：最后，在 Webpack 配置中明确告知 sass-loader 使用哪个 Sass 实现：implementation: require("sass")。这能确保它不会读取系统中可能残留的 node-sass。

对于 Vue CLI 用户，需注意：@vue/cli-service@4.x 版本默认集成了 sass-loader@10，你需要手动升级到最新版；而 @vue/cli-service@5+ 已内置对 Dart Sass 的兼容支持。

@use：不止是语法糖，更是性能核心

许多人仅将 @use 视为 @import 的替代品，这低估了它的价值。其性能收益来源于编译器级别的缓存机制：同一个模块（无论是内置模块如 "sass:math"，还是项目内的 "utils/functions"）在整个项目中只会被解析一次，后续使用仅进行符号表查询。相比之下，@import 每次都会将文件内容全文展开，重新执行变量绑定和 mixin 展开的流程。

• 反面案例：在30个组件中都使用 @import "variables";，编译器会重复执行30次完全相同的解析工作。
• 正确做法：使用 @use "variables" as v;，解析一次，处处复用。

当然，使用 @use 时也需避开一些常见问题：

• 尝试 @use "/styles/_mixins.scss" 会失败，因为以下划线开头的文件被视为私有文件。要么去掉下划线并重命名，要么通过一个主文件使用 @forward 导出。
• 一个更隐蔽的陷阱是：在 Webpack 的 additionalData 选项中写入 @use 语句。这会导致每个独立的 .vue 或 .scss 文件都触发一次独立的模块解析，完全抵消了缓存带来的性能优势。

编译依然缓慢？检查这三处配置“黑洞”

即便成功换用 Dart Sass，如果配置不当，性能仍可能大打折扣。以下三处是常见的“性能黑洞”：

1. includePaths: ["node_modules"]：这个配置常被忽略，但它会引发 I/O 灾难。编译器会递归扫描整个庞大的 node_modules 目录来查找 @use 的目标文件。
2. 生产环境开启 sourceMap: true：生成 Source Map 的耗时可能占到总编译时间的40%以上。该功能在开发阶段非常有用，但在生产环境构建时务必关闭。
3. 无限制的监听：使用 sass --watch 时未限定监听路径，导致修改一个 _button.scss 文件，却触发了整个依赖图的重编译。

归根结底，真正影响编译速度的往往不是某一行代码执行缓慢，而是模块的组织粒度和路径的解析方式。例如，如果将50个设计变量都塞进一个庞大的 tokens.scss 文件里，那么即使只修改其中一个 $color-primary 的值，整个模块的缓存都会失效，导致所有依赖它的文件都需要重新编译。模块拆分过于粗放，其效果与未拆分几乎无异。