SCSS additionalData 中路径别名不被解析，需用 path.resolve(__dirname, 'src/styles/variables.scss') 拼绝对路径；additionalData 与 modifyVars 是覆盖而非叠加关系；HMR 失效常因文件未被监听或语法错误导致整页刷新。
SCSS additionalData 中的路径别名不被解析
你写了 @import "@/styles/variables.scss"，Vite 的 CSS 插件能识别这个文件，但 Less/Sass 引擎在编译时根本看不到别名——它只认绝对路径或相对路径。结果就是变量文件压根没加载，改了也不触发 HMR，连错误都不报。
- 必须用
path.resolve(__dirname, 'src/styles/variables.scss')拼出绝对路径，__dirname是关键，process.cwd()在 monorepo 里会指向错误目录 - Windows 下如果手动拼字符串（比如
__dirname + '\src\styles\...'），反斜杠可能被当成转义符，直接导致路径解析失败 - 加一行
@debug "loaded";到 variables.scss 开头，终端没输出就说明文件根本没进编译流程
additionalData 和 modifyVars 变量冲突
二者不是叠加关系，而是覆盖关系：additionalData 是前置注入，相当于每个 .scss 文件开头都自动插入了 @import；modifyVars 是传给 sass.render() 的顶层参数，对 @import 进来的子文件无效。如果你同时配了它们，同名变量大概率被 additionalData 覆盖。
- 建议统一用
additionalData管理全局变量，稳定且可预测 - 若必须用
modifyVars（比如运行时切换主题），确保它不与additionalData中定义的变量重名 - 生产构建时路径拼错会导致编译失败，而开发时只是 HMR 静默失效，更难排查
SCSS 编译缓存未正确失效
Vite 对 SCSS 的 HMR 依赖于文件变更事件能否准确触发重新编译。当 additionalData 注入的文件本身被修改，但 Vite 没监听到它的 change event，整个链路就断了——不是 HMR 失效，是上游输入没进来。
- 运行
vite --debug css，改一次 variables.scss，看日志里有没有该文件的change记录 - 如果没出现，检查
server.watch.ignored是否误排除了src/styles/** - Linux/macOS 下注意 inotify 限制：
cat /proc/sys/fs/inotify/max_user_watches如果是 8192，大概率漏监听；临时调大：sudo sysctl fs.inotify.max_user_watches=524288
SCSS 语法错误导致 HMR 回退为整页刷新
SCSS 编译失败时，Vite 默认不会中断 HMR 流程，而是降级执行页面刷新。你看到“样式闪一下又恢复”，往往是因为变量计算出错、嵌套过深或 @extend 引用不存在的选择器，编译器静默 fallback 了。
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器 DevTools 的 Console，找
[vite] error while updating dependencies或 Sass 相关警告 - 在
vite.config.js中临时加css: { devSourcemap: true }，让错误定位更准 - 避免在
additionalData中写复杂逻辑（比如条件@if），这类代码一旦出错，HMR 很难精准定位更新范围
additionalData 路径拼错却无任何提示，或者变量冲突后你以为改了实际没生效——这些环节没有日志、没有报错、只有“看起来像好了”的假象。 
