直接换用Dart Sass可提升冷启动30%~50%，但必须同步禁用@import、关闭sourceMap、清理additionalData，否则解析逻辑瓶颈仍在；@use混用@import或全局注入变量会导致重复编译与性能退化。
直接换掉 node-sass，用 sass（Dart Sass）是最快见效的一步——冷启动快 30%~50%，增量编译优势更明显；但光换包没用，必须同步调整 @use 写法、关掉 sourceMap、清理 additionalData，否则性能卡点照旧。
为什么 sass-loader 越来越慢？不是 CPU 不够
核心问题是解析逻辑本身：每遇到一个 @import 就要重新加载、词法分析、作用域合并；变量/mixin 可见性检查随文件数增长呈指数级变重。PostCSS 没这问题，因为它不解析逻辑，只做字符串/AST 变换。
- 项目里有 20+ 个
@import的 SCSS 文件？编译时间可能翻 3 倍以上 - 用了
@use但混着@import？Sass 会回退到旧解析模式，失去模块化优势 - 全局
additionalData注入了大段 mixin 或变量？每次编译都重复解析一遍
必须改掉的三个关键配置
这些改动不依赖新工具链，Webpack/Vue CLI/Grunt 全适用：
- 禁用
@import，改用@use+ 显式路径：@use "@/styles/mixins" as *，不能省略@/或写../mixins -
sourceMap: false—— 生产环境开启它不仅没调试价值，还会让sass-loader多读一次 .map 文件并嵌入 base64 内容 - 把全局变量抽成独立文件（如
variables.scss），用@use引入；别拼字符串塞进additionalData
additionalData 是隐藏的性能黑洞
在 vue.config.js 或 Webpack 配置里用 additionalData 注入 SCSS，会让每个 .vue 组件里的 <style lang="scss"></style> 都重新执行一遍完整编译流程——项目有 80 个组件，同一份 variables.scss 就被完整编译 80 次。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：只在
main.js或入口 CSS 文件中import一次 - 若必须全局可用，也应拆成仅含
$variables和@mixin的极简文件，不带任何实际样式规则 - 检查
additionalData是否含@warn或条件块——这些在compressed模式下会被静默丢弃，上线后“消失”难排查
Grunt 用户注意 grunt-contrib-sass 的陷阱
它默认依赖 Ruby Sass，已停更多年；即使你本地装了 Dart Sass，插件仍可能 fallback 到旧实现。真正有效的提速动作是：
- 卸载 Ruby：
gem uninstall sass（避免冲突） - 改用纯 JS 实现：
npm install sass --save-dev，然后在 Gruntfile.js 中显式指定：implementation: require('sass') - 启用
update: true开启增量编译，但必须配合cacheLocation指向项目内目录（如.sass-cache），否则缓存无效
最容易被忽略的是 includePaths 里混进了 node_modules 根目录——这会让编译器递归扫描整个 node_modules 查找 @use 目标，I/O 开销远超语法解析本身。
