必须切换到 dart sass 并改用 @use：@import 会重复解析同一文件，导致编译时间指数级增长；node-sass 已停更且不支持新特性，卸载后需配置 sass-loader ≥12.6 并显式指定 implementation，同时关闭 sourcemap、设 outputstyle 为 compressed。
编译慢不是项目变大了才出现的，而是旧解析模式在文件数增长后指数级恶化；必须切换到 Dart Sass，并配合 @use 和显式配置，否则换包也白换。
为什么@import会让编译速度崩掉
Sass 每次遇到 @import 都要重新加载、词法分析、合并作用域——哪怕同一文件被 import 30 次，就解析 30 遍。这不是 CPU 不够，是解析器设计决定的开销模式。
- 20+ 个
@import的 SCSS 文件？编译时间可能翻 3 倍以上 -
@use+@forward支持模块级缓存：同路径模块只解析一次，后续全是符号查表 - 混用
@import和@use？Sass 会自动降级回旧解析模式，@use白写了 - 私有文件名带下划线（如
_mixins.scss）不能被@use直接引用，会报错
不换 node-sass 就永远卡在慢速原点
node-sass 是 LibSass 的封装，2020 年已停更。它不支持 @use、安装失败率高、Node 16+ 下需 Python 2.7 编译，且解析逻辑天生比 Dart Sass 慢 3–5 倍。
- 运行
npm uninstall node-sass—— 必须卸干净，残留会导致 loader 自动 fallback - 装
sass（不是sass-embedded，除非你明确需要进程复用）：npm install sass sass-loader@latest --save-dev - Webpack 配置里加
implementation: require('sass')，否则sass-loader仍可能找node-sass -
sass-loader版本必须 ≥ 12.6，低版本直接忽略implementation字段
sourceMap 和 outputStyle 是生产构建两大隐形拖累
开发时开 sourceMap 合理，但生产环境开启它，等于让每个 SCSS 文件额外读一次 .map、base64 编码、拼进 CSS 底部，体积暴增且毫无调试价值。
- 显式设
sourceMap: false，别依赖默认值（Dart Sass v1.80+ 默认为true） -
outputStyle必须设为'compressed'，否则css-minimizer-webpack-plugin只能压缩已生成的冗余字符串，无法重编译 -
additionalData里塞全局变量？每次编译都重复解析一遍，抽成独立variables.scss文件 +@use引入才对 -
includePaths: ['node_modules']是 I/O 灾难——编译器真会递归扫整个node_modules找@use目标
真正卡住的地方，往往不是某行语法写错了，而是 sass-loader 在反复 resolve 同一个路径、或为没用的 @debug 和注释做无意义解析。删掉 node-sass 只是第一步，漏掉 @use 改写或 sourceMap 关闭，性能照样打骨折。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
