CSS HMR慢与cssCodeSplit无关，真正原因在于未启用css.devSourcemap、未使用lightningcss transformer、server.watch.ignored配置不当，以及动态拼接CSS或远程@import等绕过模块系统的写法。
CSS HMR 慢和“CSS预构建”根本不是一回事——Vite 没有“CSS预构建”这个功能，cssCodeSplit、optimizeDeps 都不处理开发时的 CSS 热更新。真正拖慢 HMR 的，是 sourcemap 缺失、transformer 低效、watch 误触发，以及绕过模块系统的写法。
为什么改个 .css 文件要等 1–2 秒？
这不是构建慢，是 Vite 开发服务器在“猜”该更新哪部分：没有 devSourcemap，它就只能整文件 reload；用了 @import 或动态注入，它压根收不到变更通知。
- 浏览器 DevTools 里看不到源文件定位（比如显示
style.css:12而不是Button.module.css:8）→ 几乎肯定没开css.devSourcemap - 改一个变量，整个组件样式闪一下 → 可能用了
url()引字体或 SVG，或 SCSS 嵌套过深导致 AST 重建耗时 - HMR 日志里频繁出现
transforming css→ 默认的esbuildtransformer 在 v6.3.2+ 下已被lightningcss明确超越
css.devSourcemap: true 是 HMR 精准更新的前提
不开它，Vite 就没法把浏览器里渲染的样式规则，映射回你编辑的源文件行号，只能保守地重载整个 CSS 模块链。
- 必须设为
true，不能省略或写成"inline"（Vite 不支持该值） - 对 CSS Modules、
@layer、:is()等现代语法同样生效 - 内存开销极小，实测增加不到 5MB，但可将 HMR 延迟从 >1s 降至
css.transformer: 'lightningcss' 在 v6.3.2+ 中必须启用
Vite 6.3.2 起，lightningcss 已成为 CSS 处理的事实标准：编译快、错误提示准、压缩更稳。默认的 esbuild 仅用于兜底兼容。
立即学习“前端免费学习笔记（深入）”；
- 若项目用 CSS Modules，务必同时配
css.lightningcss.cssModules: { auto: true }，否则 HMR 会降级为全量重载 - 禁用
postcss.config.js时，lightningcss仍能处理nesting、custom-media等特性 - 远程
@import（如@import 'https://cdn.example.com/main.css'）永远无法被 HMR 监听，必须转为本地引用
server.watch.ignored 防止监听抖动
哪怕只改了一个 index.css，如果 node_modules 或 dist 下有文件变动，Vite 也可能触发冗余重编译。
- 明确排除
['**/node_modules/**', '**/dist/**']，这是最安全的 baseline - 不要加
**/*.css这类通配——这会直接让 HMR 失效 - Windows 用户注意路径分隔符，统一用
/，Vite 内部会自动 normalize
最容易被忽略的点：所有优化都建立在“CSS 被 Vite 模块系统正确加载”的前提下。JS 里 document.createElement('style')、fetch('/style.css').then(...)、甚至 SASS 里的 @import 'theme/_vars.scss'（路径未以 ~ 或 @ 开头），都会让 HMR 彻底失效——这不是配置能救的，得改写法。
