根本原因是additionaldata导致变量文件被重复解析数十上百次，尤其配合@import时会触发sass每次重跑整条@import链并合并符号表，叠加路径错误、调试语句、动态字符串等进一步破坏缓存。
为什么开启 additionalData 后 Sass 编译变慢
根本原因不是变量注入本身，而是 Vite 每次编译 SCSS 文件时，都会把 additionalData 内容（比如 @use "@/styles/variables.scss" as *;）拼接到文件头部，再交给 Sass 解析器处理。这意味着：同一份变量文件被重复解析几十甚至上百次——尤其当项目里有大量 <style lang="scss"></style> 组件时。
additionalData + @import 是性能黑洞
如果你在 additionalData 里用了 @import（而非 @use），Sass 会为每个组件重新执行一遍变量文件的全部作用域解析和递归 @import 展开，导致 AST 构建开销指数级增长。
-
@import是全局污染式引入，每次都会合并符号表，变量冲突检查成本高 -
@use是模块化引入，Sass 可缓存已解析的模块，但as *会削弱这部分优化 - 若变量文件里还嵌套了
@import "mixins.scss"或@import "functions.scss"，每编译一个组件就重跑一次整条链
真正拖慢编译的隐藏因素
除了写法，以下配置或结构会让 additionalData 的代价被放大：
- 变量文件路径用了相对路径（如
../styles/variables.scss），Vite 无法稳定命中缓存，每次视为新内容 - 变量文件里包含
@debug、@warn或未注释掉的测试代码，Sass 解析器仍需执行逻辑判断 - 项目启用了
sass-embedded，但没配quietDeps: true，导致日志输出成为 I/O 瓶颈 - Vite 的
css.preprocessorOptions.scss.additionalData值是动态拼接的字符串（比如含process.env.NODE_ENV），破坏了缓存键一致性
怎么验证是不是它拖慢了编译
临时注释掉 additionalData 配置，用最简方式复现编译：
- 新建一个空
test.scss，只写.x { color: red; } - 运行
vite build --watch并修改该文件，观察控制台从 “Compiling” 到 “Done” 的耗时 - 再恢复
additionalData，对比同一操作的耗时变化 - 如果差值 >300ms，且项目有 >50 个 SCSS 组件，基本可锁定是
additionalData的重复解析问题
@import 或路径写错一个点，都可能让编译时间翻倍——这种细节不会报错，但会在 dev server 启动和 HMR 时持续拖慢你。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
