HMR核心目标是改代码不刷新页面、不丢失状态，由开发服务器、构建工具、框架loader和浏览器运行时协同实现；Vue CLI基于Webpack默认启用devServer.hot并集成vue-loader，Vite原生支持HMR且通过chokidar监听与模块图精准更新，两者均零配置自动注入客户端逻辑。
HMR（Hot Module Replacement，热模块替换）在 Vue 开发环境中，核心目标是：改一行代码，页面不刷新，状态不丢失。它不是“魔法”，而是一套协同工作的机制，由开发服务器、构建工具、框架 loader 和浏览器运行时共同完成。
Vue CLI 或 Vite 中 HMR 是怎么自动启用的？
Vue CLI 基于 Webpack，默认开启 devServer.hot: true，并内置 vue-loader；Vite 则原生支持 HMR，无需额外配置。两者都默认注入 HMR 客户端逻辑，开发者几乎零配置就能使用。
- Vue CLI 启动
npm run serve时，webpack-dev-server启动 WebSocket 服务，并将hot-update.json和更新 chunk 推送到浏览器 - Vite 启动
npm run dev时，用chokidar监听文件，通过内存中的模块图精准定位变更影响范围，直接按需发送 ESM 模块更新 -
vue-loader（Webpack）或@vitejs/plugin-vue（Vite）负责把单文件组件（.vue）拆解为 script / template / style 模块，并为每部分注册 HMR 处理逻辑
Vue 组件如何实现“状态保留”的热更新？
关键不在 HMR 本身，而在 Vue 的响应式系统与 HMR 钩子的配合。当 App.vue 更新时，HMR runtime 不会销毁整个组件实例，而是触发其内部的重渲染流程。
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- template 更新 → 重新生成 render 函数 → 触发
patch过程，只更新 DOM 差异部分 - script 更新 → 若导出的是
defineComponent或 Options API 对象，vue-loader会调用module.hot.accept，用新选项合并/替换旧组件定义，但复用已有实例的data、ref、computed等响应式状态 - style 更新 → 直接替换
<style>标签内容，不涉及 JS 状态，天然无损
HMR 更新时，谁在决定“该更新哪些模块”？
依赖图（Module Graph）是决策核心。无论是 Webpack 还是 Vite，都会在启动时或首次请求时构建模块间 import 关系。
立即学习“前端免费学习笔记（深入）”；
- 比如修改
utils.ts，Vite 查模块图发现Header.vue → utils.ts，再发现App.vue → Header.vue，就确定需要通知Header.vue和App.vue所在模块更新 - Webpack 则通过
HotModuleReplacementPlugin分析编译产物差异，结合依赖关系生成manifest（如a1b2c3.hot-update.json），明确列出变更模块 ID - 这个过程确保不会误更新无关模块，也避免了全量重载，是 HMR 快速、精准的基础
为什么有时候改了代码，HMR 却没生效？
常见原因不是 HMR 失效，而是模块未正确声明可接受更新，或框架层拦截了替换逻辑。
- 纯 JS 模块（如
math.js）若没写if (module.hot) module.hot.accept(...)，Webpack 默认不处理，会 fallback 到 Live Reload - Vue 组件中使用了
new Vue()或非标准挂载方式，可能绕过 vue-loader 的 HMR 包装逻辑 - 顶层组件（如
main.js中的createApp(App).mount()）一般不接受热替换，所以改App.vue可以，但改main.js通常仍会整页刷新 - Vite 中若用了动态
import()且未显式import.meta.hot.accept，也可能中断 HMR 链路
