vue.config.js中用additionalData注入SCSS会导致每个.vue组件重复编译N次，而非单次；应改在main.js中导入，或拆为仅含变量/混入的极简文件。
SCSS 编译慢，根本原因往往不是语法本身，而是构建链路中多个环节的冗余处理、错误配置或隐式开销叠加。直接改 sass 参数只能缓解表象，真正卡顿多来自 loader 链错配、全局注入滥用、PostCSS 插件过载这三类问题。
vue.config.js 里用 additionalData 注入 SCSS 文件为什么特别慢
这不是“加个变量而已”的轻量操作——它会让每个 Vue 单文件组件（.vue）里的 <style lang="scss"> 都重新执行一遍完整的 SCSS 编译流程，包括变量解析、@import 展开、mixin 展开等。
- 项目有 80 个组件？那同一份
variables.scss就被完整编译 80 次 - 哪怕只改了一个
$spacing-sm值，所有组件样式都会重跑编译 - 如果
additionalData里还写了@import "mixins"+@import "theme"，嵌套层级越深，重复解析成本越高
正确做法是：只在 main.js 或入口 CSS 文件中 import 一次，让 Webpack 把它当作普通依赖走单次编译；若必须全局可用，也应拆成仅含 $variables 和 @mixin 的极简文件，不带任何实际样式规则。
PostCSS 插件顺序和默认行为正在拖慢你的构建
postcss-preset-env 和 cssnano 是最常被误用的两个插件。它们在开发阶段反复解析你根本没写的语法（比如 :is()、color-mix()），或在生产环境无差别压缩 SVG 和注释，导致 CPU 占用飙升、内存溢出、source map 错位。
立即学习“前端免费学习笔记（深入）”；
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 开发环境禁用
cssnano，只留postcss-custom-properties+autoprefixer - 生产环境启用
cssnano时，显式关闭高开销项：{ svgo: false, discardComments: { removeAllButFirst: true } } -
postcss.config.js中插件顺序必须是：postcss-custom-properties→ 其他转换插件 →autoprefixer（补全放最后，避免重复计算）
用 DEBUG=* 启动构建，搜日志里 postcss-preset-env 的 parse 调用次数，如果远超 CSS 文件数，说明它正在空转。
loader 链中的 importLoaders 设错一层，整个优化就白做
这个参数控制的是「当前 CSS 文件里 @import 进来的文件」会经过几个 loader 处理。设错会导致 loader 反复调用、报错或跳过关键处理。
- loader 配置是
[css-loader, postcss-loader, sass-loader]→importLoaders: 2（让被 import 的文件进后两个） - 但如果你已弃用
sass-loader，只用 PostCSS 处理变量，却还设importLoaders: 2，就会触发Error: Cannot find module 'sass' - 更常见的是设成
1，结果@import 'theme.css'里的 CSS 变量没被postcss-custom-properties解析，最终浏览器报Invalid property value
检查方法：在任意 .css 文件里写一行 @import "./vars.css";，然后看 vars.css 是否能正确解析 var(--color-primary) —— 不能，就是 importLoaders 没对上链长。
真正影响编译速度的，从来不是 precision 或 outputStyle 这类表面参数，而是 loader 之间是否互相推诿、PostCSS 是否在替你瞎猜语法、全局注入是否把单次任务变成 N 次重复劳动。这些地方一旦错位，改再多次 sass.render() 也没用。
