禁用@import改用@use+显式路径、关闭sourcemap、抽出additionaldata全局变量，三步可降编译时间40%以上；@use模块化仅首次解析，sourcemap对sass调试无效且增io开销，additionaldata导致重复编译。
直接换掉 @import，关掉 sourceMap，把全局变量从 additionalData 里抽出来——这三步做完，多数项目 Sass 编译时间能压掉 40% 以上。
禁用 @import，改用 @use + 显式路径
Sass 的 @import 是性能黑洞：每次遇到就重加载、重解析、重合并作用域，文件一多，编译时间指数级上涨。而 @use 是模块化设计，只在首次引入时解析，后续复用 AST。
-
@use "@/styles/variables" as *;✅ 显式路径，支持 Webpack 别名解析 -
@use "../mixins";❌ 相对路径跳转，sass-loader无法稳定定位，易触发全量重编 -
@use "bootstrap/scss/functions";✅ node_modules 内路径可直接写，但需确保includePaths没把node_modules根目录加进去（否则会递归扫描整个node_modules） - 混用
@use和@import？Sass 会自动退回到旧解析模式，@use白配
关掉 sourceMap，别信“开发需要”
开发阶段开 sourceMap: true 对 Sass 几乎没用：浏览器 DevTools 里点不到 .scss 行号，真正起作用的是 CSS Source Map（由 css-loader 或 style-loader 生成），不是 Sass 层的。
-
sourceMap: false必须设 —— 否则sass-loader每次都要读一次 .map 文件，再 base64 嵌入输出，纯 IO 开销 - 如果真要调试变量或 mixin 展开，用 VS Code 的 Sass 插件或直接看编译后 CSS 更快
- 生产环境绝对禁止开启，毫无价值还拖慢构建
别用 additionalData 注入全局 SCSS
additionalData 看似方便，实则是隐形编译炸弹：Webpack 每处理一个 .vue 或 .scss 文件，就把它拼进开头再完整跑一遍 sass-loader 流程。
- 80 个组件？同一份
variables.scss就被重复编译 80 次 - 正确做法：只在项目入口 CSS（如
main.scss）里@use "variables"一次 - 若必须全局可用，抽一个极简文件（只含
$color-primary、@mixin clearfix），不带任何.btn这类样式规则 - 检查
additionalData里有没有@warn或@if—— 这些在compressed模式下会被静默丢弃，上线后“消失”很难定位
Grunt 用户注意 grunt-contrib-sass 的 Ruby 陷阱
很多老项目还在用 grunt-contrib-sass，它默认走 Ruby Sass（已停更多年），即使你本地装了 Dart Sass，插件也可能 fallback 到旧实现，导致缓存失效、语法不兼容、速度更慢。
- 卸载 Ruby Sass：
gem uninstall sass - 改用 JS 版：
npm install sass --save-dev - 在
Gruntfile.js中显式指定：implementation: require('sass') - 加上
cacheLocation: '.sass-cache'和update: true才算真正启用增量编译
最容易被忽略的其实是 includePaths 里塞了 node_modules 根目录——这不是配置，是给编译器发了个“全盘扫描”指令，I/O 时间远超语法解析本身。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
