热更新十次后内存从 80MB 涨到 300MB，同一个 action 打印十一次日志。页面切换五次，请求也发五次。日志里能对上时间点，这种反而好排。
subscribe 返回的取消函数被丢掉，模块热更新时又注册一次，旧监听一直指着已卸载的组件。监听里没有判空，还在继续 setState。这一点先确认清楚，后面就不用反复试。
useEffect(() => {
const un = useStore.subscribe(handle);
return un;
}, []);
围绕「store 订阅泄漏」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。
改完顺手把文档补一句，省得下次自己重新推一遍。监控和日志的时间要对上，时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
处理上按这个顺序：把 unsubscribe 存下来 在清理函数里调用；用 useEffect 注册订阅 依赖只写 store 本身；HMR 场景在 dispose 钩子里取消；连续热更新十次 看日志是否只打一条。
结果对不对很好判断，热更新十次后一次 action 只打印一条日志，内存稳定在 80MB 左右。