Vite 热模块分析插件

你要排查的问题

Vite 的 HMR 在项目变大之后经常“看起来热更新了，但没完全热更新”：按下保存，页面确实刷新了一部分模块，但几秒后白屏、状态丢失，或者某个深层依赖被重新求值，控制台里只剩一串 update 调用。

真正难回答的不只是“为什么失效”，而是“这次 update 链路经过了哪些模块，哪一段耗时最多”。原生 dev server 在 ws 事件里只告诉你模块失效了，不给链路顺序和相对耗时；手动打断点、看 Network 面板只能拿到零碎片段，很难还原完整的依赖图。

技能如何工作

它从两个入口采集数据：

• 插件 API：在 vite.config.ts 中注册插件，钩住 handleHotUpdate、transform 等生命周期，拿到每次 HMR 涉及的模块列表和父子依赖关系。
• WebSocket 事件：监听 dev server 的 ws 推送，记录 update、error 等事件的时序，给链路中的每个模块打上接收顺序和相对耗时。

采集完成后按模块边界聚合：

• 找出更新链里耗时占比最高的模块边界，也就是真正拖慢 HMR 的那一环。
• 检测循环依赖的热路径——A 依赖 B、B 又依赖 A 时，每次保存都可能触发多余重求值。
• 整理成 Chrome DevTools Performance 面板可导入的火焰图格式，贴进 performance trace 逐帧展开。

适用边界

• 只覆盖 Vite dev server 场景，不适用于生产构建，也不覆盖 webpack、Turbopack 等其它 bundler。
• HMR 分析依赖 dev server 实际推送的 ws 事件；如果项目自定义了 runtime 或绕开了 Vite 的模块图，链路会不完整。
• 火焰图输出是诊断材料，不是自动优化工具：它能指出慢在哪，但不会自动拆模块或改写依赖。