JavaScript单页应用内存无限增长的本质是对象被隐式引用而无法被GC释放，需在组件卸载时清理事件、定时器等副作用，避免全局监听、滥用闭包，合理使用WeakMap，严格管控缓存，并用Chrome DevTools验证内存是否真正释放。
JavaScript 单页应用（SPA）内存无限增长，本质是对象持续被隐式引用而无法被垃圾回收器（GC）释放。它不会立刻报错，但反复打开关闭模块、切换路由、轮询数据后，内存阶梯式上升，最终卡顿甚至崩溃。核心不是“内存用得多”，而是“该走的没走”。
组件卸载时必须清理副作用
SPA 中组件频繁挂载/卸载，但事件、定时器、观察者若未显式清理，其回调闭包会锁住整个作用域链。
- React：在 useEffect 返回函数中调用
removeEventListener、clearInterval、abortController.abort()、observer.disconnect() - Vue：在 onBeforeUnmount 或 beforeDestroy 中执行对应清理逻辑
- 原生 JS：为每个可销毁对象提供明确的
destroy()或teardown()方法，并确保调用 - 避免给
window或document绑定全局监听器——改用事件委托或限制监听范围
慎用闭包，尤其别长期持有 DOM 或大对象
闭包本身无害，但当它被长生命周期对象（如未清除的定时器、缓存 Map、全局事件总线）持有时，就会拖住整个外层作用域。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 事件回调中不要直接捕获整个容器节点：
const container = document.getElementById('list')→ 改为只存container.id或container.dataset.key - 需要关联状态时，优先用 WeakMap：
const cache = new WeakMap(); cache.set(el, { loaded: true })—— DOM 被移除后自动清理 - 大型数组、响应数据、Canvas 上下文等，不用时主动置为
null，切断引用链
严格管控全局与缓存生命周期
SPA 不刷新页面，全局变量和缓存一旦创建就可能永远存在。
立即学习“Java免费学习笔记（深入）”；
- 开启 "use strict"，防止漏声明变量意外挂到
window上 - 禁用隐式全局写入：检查
console.log(this)是否指向window，排查this绑定错误 - 缓存必须设上限 + 淘汰策略（如 LRU），或改用 WeakMap / WeakSet 存储仅需临时关联的数据
- 避免
console.log大对象（如完整响应体、DOM 树）—— 开发阶段也会影响 GC，上线前应剥离或限制输出
用工具验证“是否真释放了”
不靠感觉，靠 Chrome DevTools 定量判断：
- 打开 Memory 面板 → 拍摄堆快照（Heap Snapshot）：操作前拍一次，打开模块再关闭后拍一次，对比 Objects allocated between snapshots
- 重点关注异常增多的类型：
Closure、HTMLDivElement、Array、自定义类名；点开看 Retainers 找谁在持有着它 - 点击 Collect garbage（回收站图标）强制 GC，若内存不回落，说明有强引用阻止释放
- 启用 Allocation instrumentation on timeline，录制关键操作，观察蓝色小方块是否持续新增且不回落
