必须替换node-sass为sass（Dart Sass），因其已停更、不支持新语法、安装易失败且编译慢；迁移需三步：卸载node-sass、安装sass与新版sass-loader、Webpack中显式指定implementation。
直接换掉 node-sass，用 sass（Dart Sass）是提升编译速度最有效、最省事的一步——实测冷启动快 30%~50%，增量编译优势更明显。
为什么 node-sass 必须被替换
LibSass 已于 2020 年 10 月正式停止维护，node-sass 只是它的 Node.js 封装，不再接收任何功能更新或安全修复。你遇到的以下问题，根源几乎都指向它：
-
npm install node-sass在 Node 16+ 环境下频繁失败（需 Python 2.7、node-gyp 编译） - CI 流水线因二进制下载超时中断
- 用了
@use却报Invalid CSS after "@use"——node-sass根本不支持模块语法 - 升级 Webpack 或 sass-loader 后构建崩了，查半天发现是版本链断裂（
sass-loader@12要求sass，不兼容node-sass）
迁移只需三步，但必须按顺序执行
跳过任意一步都可能引发静默错误或回退到旧行为：
- 运行
npm uninstall node-sass—— 不要保留旧包，避免 loader 自动 fallback - 运行
npm install sass sass-loader@latest --save-dev——sass-loader@12+才完整支持@use和模块缓存 - 在 Webpack 配置中显式指定实现：
implementation: require("sass")，否则仍可能读取残留的node-sass
Vue CLI 用户注意：@vue/cli-service@4.x 默认带 sass-loader@10，需手动升级；@vue/cli-service@5+ 已内置兼容 Dart Sass。
立即学习“前端免费学习笔记（深入）”；
@use 不是语法糖，它是提速核心机制
@use 的性能收益来自编译器级缓存：同一路径模块（如 "sass:math" 或 "utils/functions"）在整个项目中只解析一次，符号表复用。而 @import 每次都全文展开、重走变量绑定和 mixin 展开流程。
- 错误写法：
@import "variables";放在 30 个组件里 → 编译器执行 30 次相同解析 - 正确写法：
@use "variables" as v;→ 解析一次，后续只是符号查表 - ⚠️ 坑点：
@use "/styles/_mixins.scss"会失败（私有文件不能直接@use），应改名mixins.scss或用@forward导出 - ⚠️ 更隐蔽的坑：
additionalData中写@use—— 这会让每个 .vue 文件都触发独立模块解析，完全抵消缓存价值
编译慢？先检查这三处配置黑洞
即使用了 Dart Sass，常见配置失误仍会让性能打骨折：
-
includePaths: ["node_modules"]—— 最常被忽略的 I/O 灾难，编译器会递归扫描整个node_modules查找@use目标 -
sourceMap: true在生产环境开启 —— 生成映射耗时可占总编译时间 40% 以上，开发阶段启用即可 -
sass --watch未限定路径 —— 默认监听全部子目录，改一个_button.scss却重跑所有@forward依赖图
真正影响速度的不是单行代码，而是模块组织粒度和路径解析方式。把 50 个变量塞进一个 tokens.scss，哪怕只改一个 $color-primary，整个模块缓存也会失效——拆得过粗，和没拆一样。
