根本原因是css-loader与style-loader（或开发模式下配置hmr的MiniCssExtractPlugin.loader）在构建时已封装module.hot.accept()及样式替换逻辑，使CSS模块自带热更新能力；而JS模块需手动编写module.hot.accept()才能定义更新行为。
CSS 文件被 loader 处理后自带 HMR 接入逻辑
根本原因不是“引入方式”，而是 css-loader + style-loader（或开发模式下的 MiniCssExtractPlugin.loader）在构建时已将 module.hot.accept() 和样式替换逻辑封装进模块导出中。你写 import './index.css'，实际加载的是一个“已预埋热更新能力”的模块，Webpack 运行时一收到更新通知，就能直接执行卸载旧 <style>、插入新标签的操作。
而 JS 模块默认不带任何更新策略 —— Webpack 只注入了 HMR runtime 基础能力，但不会替你决定“改完之后怎么清理旧实例、怎么重建新状态”。没写 module.hot.accept()，runtime 就只能 fallback 到整页刷新。
为什么 style-loader 能自动热更新，MiniCssExtractPlugin.loader 却经常失效？
关键在 loader 的运行时行为差异：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
-
style-loader在 DOM 中动态插入<style>标签，并在内部调用module.hot.accept()，重写了insertStyleElement流程，实现样式节点级替换 -
MiniCssExtractPlugin.loader默认用于生产环境，提取为独立.css文件；即使在mode: 'development'下启用，也需显式配置hmr: true，且要求 Webpack ≥ 5.47.0 - 若误配
MiniCssExtractPlugin.loader且未开hmr，控制台会静默降级 —— 实际走的是文件替换 + 强刷<link>href，但没加时间戳防缓存，导致样式看似没变
module.hot.accept() 在 JS 模块里到底要怎么写？
不是加一行就完事，得匹配模块类型和使用场景：
- 纯工具函数（如
utils.js）：通常无需热更新，改了直接整页刷新更安全；硬要支持，得在dispose里清掉可能挂载的全局监听器或定时器 - React 组件：推荐用
react-refresh（Vite / Webpack 5+ 内置），它会自动包裹组件并注入 HMR 钩子，比手写accept更可靠 - 根模块（如
main.js）：必须写module.hot.accept('./App', () => { render(App); })，否则 HMR runtime 不知道该触发哪段重渲染逻辑 - 错误现象：
[HMR] Cannot apply update. Need to do a full reload.—— 说明变更模块没声明接受更新，或accept回调里抛了错
HMR 看似自动，但 CSS 更新频繁时真没副作用？
有。每次热更新都会触发一次 DOM 插入/移除操作，如果：
- 单次更新包含大量 CSS 规则（比如整个组件库样式表被 import），可能引发 layout thrashing
- 使用了 CSS-in-JS 方案（如 styled-components），其 runtime 会额外做 className 映射和重计算，性能开销比原生
style-loader更高 - 开启了 source map 且 CSS 文件过大，dev server 内存编译压力会上升，热更新延迟明显
真正容易被忽略的点是：HMR 不是“开关一开就万事大吉”，CSS 的热更新能力取决于 loader 链是否完整兼容 HMR API，JS 的热更新则完全依赖开发者对模块生命周期的理解 —— 两者机制完全不同，不能套用同一套直觉。
