改CSS页面没反应是因为该CSS未被纳入HMR链路，如被条件导入或动态插入绕过Vite解析；验证方法是加时间戳注释并检查Network是否重发请求。
为什么改了 CSS 文件页面没反应？先确认是否真进了 HMR 流程
常见现象是保存 Button.css 后样式没变，但控制台也没报错。这不是 HMR “坏了”，而是该 CSS 模块根本没被纳入热更新链路——比如它被 import 在一个被 tree-shaking 排除的条件分支里，或通过 document.createElement('style') 动态插入（绕过了 Vite 的模块解析）。验证方法：在对应 CSS 文件顶部加一行注释 /* hot: ${Date.now()} */，保存后看 Network 面板里浏览器是否重新请求了该文件（状态码 200，不是 304）。没重发请求？说明文件监听没触发，问题出在服务端监听层。
Vite 是如何监听 CSS 变更并推送到浏览器的
Vite 使用 chokidar 监听文件系统，但对 CSS 的处理和 JS 不同：它不依赖模块图向上追溯 importer，而是直接将变更的 CSS 文件标记为“全量更新目标”。因为 CSS 无导出、无依赖语义，Vite 把每个 CSS 文件都视为独立的 HMR 边界。当 src/assets/styles/main.css 变更时：
- Vite Dev Server 检测到文件修改时间戳变化
- 跳过依赖图分析，直接编译该 CSS 文件（走
transform钩子） - 通过 WebSocket 推送一条
{"type":"css-update","path":"/src/assets/styles/main.css","timestamp":1748172500123}消息 - 客户端
@vite/client收到后，定位到页面中已有的<link rel="stylesheet">或<style>标签，用新内容替换其textContent或href
这个过程不涉及模块 accept 声明，也不需要你在 CSS 里写任何 HMR 相关代码——它是开箱即用的。
哪些 CSS 写法会导致 HMR 失效
失效往往不是 Vite 的问题，而是你绕过了它的模块加载机制：
立即学习“前端免费学习笔记（深入）”；
- 用
fetch('/src/assets/xxx.css').then(r => r.text())+document.head.appendChild动态加载：Vite 不会监听这种路径，也不会拦截该请求 - 在
<style scoped>之外写@import 'xxx.css'：如果xxx.css是相对路径且未被 Vite 解析为模块（比如漏了./），它会被当成普通静态资源，不进 HMR 管道 - CSS-in-JS 场景（如
styled-components或emotion）：Vite 默认不接管 JS 字符串里的样式，需额外插件（如vite-plugin-styled-components）或手动调用import.meta.hot?.accept触发重渲染 - 使用
process.env.NODE_ENV === 'development'包裹import：构建时可能被摇掉，开发时又因条件判断未执行 import，导致模块未注册进 ModuleGraph
自定义 CSS 构建逻辑时如何保留 HMR
如果你在 vite.config.ts 里加了 css.preprocessorOptions 或用了 PostCSS 插件，只要不破坏原模块路径和内容输出，HMR 就继续有效。但注意两个关键点：
-
css.devSourcemap必须为true（默认开启）：否则客户端无法映射错误行号，且部分插件依赖 sourcemap 定位变更范围 - 避免在
transform钩子里把多个 CSS 合并成一个字符串再返回：这会让 Vite 丢失原始文件粒度，更新时只能全量刷整个 bundle —— 应保持每个.css文件对应一个独立的transformResult - 若用
css.postcss配置了自定义插件，确保它不修改result.root.source.input.file，否则 Vite 无法将编译结果正确挂载回原始模块节点
真正容易被忽略的是：HMR 对 CSS 的“秒级响应”只发生在开发服务器直连场景。一旦加了 Nginx 反向代理且未透传 WebSocket 升级头（Upgrade: websocket、Connection: Upgrade），HMR 就会退化为整页刷新——这时你看到的“样式更新了”，其实是页面 reload 带来的假象。
