插件无法动态修改 css.preprocessoroptions.scss.additionaldata，因其为 vite 顶层静态配置；真正可行的是在 transform 钩子中拦截 .scss 文件并前置拼接 @use 语句，或在 configresolved 中校验 additionaldata 合法性、别名路径真实性及 variables.scss 内容规范性。
插件里不能直接改 css.preprocessorOptions.scss.additionalData
因为 css.preprocessorOptions 是 Vite 的顶层配置项，只在 config 阶段解析一次，插件的 configResolved 或 configureServer 钩子无法安全覆盖它。你看到的“插件注入变量”多数是误传——真正生效的只有 vite.config.ts 里静态写的 additionalData。插件能做的，是辅助生成或校验这部分内容，而非动态接管。
想用插件控制注入逻辑，得走 configureServer + transform 钩子
如果你确实需要构建时按条件注入（比如开发环境加调试变量、生产环境屏蔽某些 mixin），可行路径是拦截 .scss 文件内容，在编译前手动拼接：
- 监听
transform钩子，匹配/\.scss$/文件路径 - 读取原始内容，用
@use "@/styles/variables.scss" as *;前置拼接（注意末尾分号和换行） - 返回新内容，跳过默认预处理器流程（需配合
preprocess插件或禁用默认 scss 处理） - 但这样会绕过 Vite 内置的 Sass 编译器缓存和 sourcemap，调试困难，且与
css.modules、scoped行为不兼容
实际项目中极少这么做——不如把条件逻辑写进 variables.scss 内部，用 $env: "dev" + @if 控制输出。
插件最实用的介入点：校验和报错提示
真正值得在插件里做的，是防止 additionalData 配错导致静默失败：
- 在
configResolved中检查config.css.preprocessorOptions.scss.additionalData是否存在、是否含@use、是否以分号结尾 - 用
fs.existsSync校验@/styles/variables.scss路径是否真实存在（别名需先 resolve） - 读取
variables.scss内容，正则扫描是否有{或body\s*{，提示“禁止在变量文件中写 CSS 规则” - 当检测到
@import时，warn 提示已废弃，建议改用@use ... as *
这类插件不改变行为，但能把常见错误提前暴露，比反复查 undefined variable 省半小时。
别名未生效就注入，路径永远解析失败
这是插件最容易踩空的一环：你以为 @/styles/variables.scss 能被 fs.realpath 解析，其实 Vite 别名只在 resolveId 阶段生效，插件里必须手动处理：
- 不能直接
fs.readFileSync("@/styles/variables.scss")—— Node 不认识@/ - 得先从
config.resolve.alias找到@对应的真实路径，再拼接styles/variables.scss - 如果 alias 是数组或函数形式（如
[{ find: '@', replacement: path.resolve('src') }]），还得做兼容判断
真正容易被忽略的，是插件里对别名的解析逻辑和 Vite 内部 resolve 流程不一致——哪怕配置完全正确，插件自己读错了路径，校验就全白做了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
