[!info] related notes

• 所属：开发服务器与 HMR
• 前置：双路径
• 后续：插件系统

Vite HMR 与模块图

这个概念为什么出现

热更新需要知道模块依赖和接受更新的边界。有了模块图，工具才能判断：谁依赖了变更模块，边界能否安全替换。

[!abstract] 一句话理解 HMR 精度取决于模块图边界 + 框架运行时是否接受补丁，不是“保存必局部更新”的魔法。

可观察实验

1. 只改展示组件文案 → 在框架接受更新的边界内通常局部更新；保留 state/输入还取决于组件身份与框架规则
2. 改入口副作用或无法接受边界 → full reload

pnpm dev
# 观察终端 hmr update / page reload 日志

模型

• 记录 import 图
• 变更模块向上寻找可接受边界
• 找不到则刷新页面

工程实践

• 定时器、订阅、事件监听等副作用应有对应清理；自定义 HMR 模块用 import.meta.hot.dispose 在替换前清理，不能仅靠把初始化移到入口
• 状态放框架 state，不依赖“模块单例碰巧存活”
• 自定义 HMR API 仅高级场景

本节总结

HMR 是模块图上的增量补丁协议；会读日志才能解释“为何这次刷新了”。

自测题

1. 改 .env 为何常需重启？

参考答案

环境变量在服务启动/构建注入路径上，通常不走组件 HMR 补丁协议。