JavaScript SPA内存健康巡检核心是主动监控与切断泄漏路径，而非干预GC：每次模块开闭、用户停留5分钟、高频交互后拍堆快照，重点关注Detached DOM、Closure及自定义实例是否异常累积，并通过WeakMap、显式清理和严格模式从代码层切断强引用链。
在长期运行的单页应用（SPA）中，垃圾回收本身是自动触发的，无法也不应由开发者“定期执行”——V8 引擎根据内存压力、分配速率等内部策略动态调度 GC。所谓“内存健康巡检”，实质是**主动监控内存状态、识别异常驻留对象、及时切断泄漏路径**，而非干预 GC 时机。
建立可重复的巡检节奏
不依赖“定时跑 GC”，而是固定行为模式，在关键生命周期节点采集数据：
- 每次核心模块打开/关闭后，立即拍一次堆快照（Heap Snapshot）
- 用户停留超过 5 分钟时，手动触发一次快照作为基线参考
- 每完成一轮高频交互（如连续增删 10 次列表项），记录分配时间线（Allocation Timeline）片段
- 在 CI 或本地预发环境集成自动化内存断言：例如用 Puppeteer 控制 Chrome，执行操作序列后比对快照中 Detached DOM tree 和 Closure 实例数是否稳定
重点关注三类高危驻留对象
巡检不是看总内存大小，而是查“不该活这么久的对象为什么还活着”：
- Detached DOM 节点：在快照 Comparison 视图中搜索 “Detached”，若数量随操作次数线性增长，说明 JS 仍持有已移除节点的引用（如缓存了 el、未清理事件监听器）
- 闭包（Closure）实例：筛选 Constructor 列为 "(closure)"，关注 Shallow Size 累计值；若某次操作后 Closure 总量激增且不回落，大概率是定时器回调、未解绑的 handler 或暴露到全局的函数捕获了大对象
- 自定义类实例持续累积：比如 MyChart、DataProcessor 等构造函数实例数只增不减，往往对应组件卸载后未销毁实例、事件监听未解绑、或 Map/Set 缓存未清理
用弱引用与显式清理替代被动等待
巡检发现泄漏，要从代码层切断强引用链，而不是等 GC “碰巧”回收：
立即学习“Java免费学习笔记（深入）”；
- DOM 元数据存储统一改用 WeakMap，键为 DOM 节点，确保节点被移除后元数据自动失效
- 所有
addEventListener必须配对removeEventListener，避免使用匿名函数；Vue 用onBeforeUnmount，React 用useEffect清理函数 - 定时器、Observer、AbortController 等“活体资源”，必须在组件销毁或逻辑退出时显式调用
clearInterval、.disconnect()、.abort() - 全局缓存加约束：用
WeakMap+ ID 计数，或带 LRU 驱逐策略的 Map，禁用无上限的const cache = {}
开发阶段辅助手段
让巡检更轻量、更早发现问题：
- 启用
'use strict'，杜绝隐式全局变量挂载（如漏写let导致window.cache） - 在关键函数退出前插入
console.debug('cleanup done')，配合 Performance 面板的 User Timing API 标记清理点 - Chrome DevTools 中勾选 Memory > Record memory allocations，开启“分配采样”，能快速定位哪行代码高频创建未释放对象
- 控制台中避免长期展开大对象，防止 DevTools 自身隐式保留引用（仅开发环境影响）
