Vite优化CSS热更新，禁用sourcemap提升速度

Vite 的 CSS 热更新速度并非靠禁用 sourcemap 来提升，恰恰相反：关闭 `css.devSourcemap` 会迫使 Vite 退化为整文件重载，导致 HMR 延迟飙升（如从 200ms 拉长至 1.5s+），而开启它不仅能精准注入局部变更、显著加速热更新，还能增强 DevTools 调试体验；真正高效的优化在于启用 `lightningcss` 作为 CSS 处理器（提速 40%+，需配合 `css.lightningcss.cssModules.auto: true`）、合理配置文件监听（如排除 node_modules 和 dist）、并杜绝绕过模块系统的写法（如动态插入 style 标签或远程 @import）——这些实践比盲目“拆分 CSS”更能根治 HMR 卡顿问题。

css.devSourcemap: false 会显著拖慢 CSS 热更新，而不是加快它——禁用 sourcemap 是常见误操作，实际会让 HMR 退化为整文件重载。

为什么关掉 css.devSourcemap 反而更慢

Vite 的 CSS HMR 依赖 sourcemap 定位变更的具体规则（比如哪条 .button:hover 被改了）。关掉后，Vite 无法判断局部变更范围，只能保守地全量刷新整个 CSS 模块链，尤其在多个组件 import 同一个 SCSS 文件时，延迟从 200ms 拉长到 1.5s+。

• 开启 css.devSourcemap: true 后，浏览器 DevTools 能精准跳转到修改行，Vite 也据此只注入变更部分
• SCSS/Sass 中嵌套层级深、@extend 多的文件，关 sourcemap 会导致 AST 重建开销翻倍
• cssCodeSplit 对开发时 HMR 完全无影响，它只控制生产构建是否拆出独立 CSS 文件

css.transformer: 'lightningcss' 是当前最有效的提速项

Vite v6.3.2+ 默认仍用 esbuild 处理 CSS，但 lightningcss 在解析和 sourcemap 生成上快 40%+，对大项目效果明显。必须配合 css.lightningcss.cssModules.auto: true 使用，否则 CSS Modules 场景下 HMR 会降级。

• 不加 cssModules 配置时，lightningcss 会跳过模块化逻辑，回退到低效路径
• 若项目用了 PostCSS 插件（如 postcss-preset-env），lightningcss 会自动兼容，无需额外配置
• 验证是否生效：启动 Vite 后看控制台是否有 [lightningcss] processed X files 日志

真正该“拆分”的不是 CSS 模块，而是监听范围

所谓“拆分模块”优化 HMR 是误解。Vite 不靠拆文件来提速，而是靠减少监听抖动和避免依赖图爆炸：

• server.watch.ignored 必须排除 **/node_modules/** 和 **/dist/**，否则 CSS 变更会触发大量无关文件重解析
• 避免在 JS 里动态拼接