关闭 css.devSourcemap 会显著拖慢 CSS 热更新，因其使 Vite 无法定位局部变更而退化为整文件重载；开启后可精准注入修改部分并提升 DevTools 调试体验。
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 里动态拼接
<style>或用fetch加载 CSS 文本——这些写法绕过 Vite 模块系统，HMR 完全失效 - 远程
@import（如@import 'https://cdn.example.com/style.css'）会被 Vite 跳过监听，导致修改后无反应
最容易被忽略的一点：HMR 延迟往往不是配置问题，而是写法问题。哪怕所有配置都正确，只要组件里有一行 document.head.appendChild(styleEl)，整个热更新链就断了——这点比任何配置开关都关键。
