如何利用Vite的CSS预构建功能提升HMR速度_通过缓存依赖项优化-css教程-PHP中文网

css hmr慢与csscodesplit无关，真正原因在于未启用css.devsourcemap、未使用lightningcss transformer、server.watch.ignored配置不当，以及动态拼接css或远程@import等绕过模块系统的写法。

如何利用vite的css预构建功能提升hmr速度_通过缓存依赖项优化

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 → 默认的 esbuild transformer 在 v6.3.2+ 下已被 lightningcss 明确超越

`css.devSourcemap: true` 是 HMR 精准更新的前提

不开它，Vite 就没法把浏览器里渲染的样式规则，映射回你编辑的源文件行号，只能保守地重载整个 CSS 模块链。

VitePress Generator

使用 VitePress 快速生成静态网站，支持安装依赖、初始化项目、本地预览、构建和部署。

下载

必须设为 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 彻底失效——这不是配置能救的，得改写法。