排查大对象缓存内存溢出的核心是定位“不该长期驻留的大对象”及其持有链：通过Chrome DevTools拍对比快照，筛选Retained Size异常高、数量增长的Object/Array/Map/Set，检查Retainers中全局变量、未解绑监听器、未清理定时器或第三方库缓存等强引用源，并结合强制GC与主动置null验证释放行为。
排查 JavaScript 中因大对象缓存引发的内存溢出崩溃，核心是定位“不该长期驻留内存的大对象”及其持有链。关键不在于单纯看内存总量，而在于识别被意外保留、无法被垃圾回收（GC）的引用路径。
用 Chrome DevTools 捕获内存快照并对比
这是最直接有效的起点：
- 打开 Chrome DevTools → Memory 面板 → 选择 Heap snapshot
- 在疑似问题场景前（如进入某页面/执行某操作前）拍一个快照；再触发缓存行为（如加载大量数据、反复打开关闭模块）后，再拍一个
- 切换到第二个快照 → 在左上角下拉选 Comparison → 选择第一个快照作为基准 → 观察 Objects allocated between snapshots 列表
- 重点关注：类型为 Object、Array、Map、Set 且 Retained Size 异常高（几 MB 以上）、数量持续增长的对象
检查常见缓存陷阱与持有者（Retainers）
快照中点击可疑对象 → 右侧查看 Retainers 面板，顺着引用链向上找“本不该活这么久”的宿主：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
全局变量或模块级闭包缓存：比如
const cache = new Map()写在模块顶层，但 key 是 DOM 元素或未清理的回调函数，导致整块数据无法释放 - 事件监听器未解绑：给某个列表项绑定 click 回调，回调里又闭包引用了整个数据项（含图片 base64、嵌套对象等），即使列表项 DOM 被移除，只要监听器没 removeEventListener，数据就一直被持有
- 定时器/请求未清理：setInterval 持有作用域中的大数据，或 axios 请求的 success 回调闭包了响应体（尤其下载大文件时返回 blob 或 arraybuffer）
- 第三方库缓存失控：如某些图表库内部缓存渲染数据、lodash.memoize 缓存了带深层结构的参数、React 组件中 useRef 保存了未序列化的大型对象
模拟 GC 并验证释放行为
不要只看快照静态数据，要验证对象是否真能被回收：
立即学习“Java免费学习笔记（深入）”；
- 在 Memory 面板点击 Collect garbage（小垃圾桶图标），强制触发 GC
- 再拍一次快照，对比前一次 —— 如果同一类大对象的实例数/Retained Size 没明显下降，说明存在强引用阻止回收
- 配合代码中主动 null 掉可疑引用（如
cache.clear(); myRef.current = null;），再 GC + 快照，观察变化，快速验证假设
加轻量级运行时监控防患于未然
在线上或复杂流程中，可注入简单检测逻辑：
- 对已知缓存 Map/Set 做 size 和单个 value 大小估算（例如用
JSON.stringify(obj).length粗略判断，仅用于开发期） - 在关键入口打日志：
console.warn(`Cache size: ${myCache.size}, est. memory: ${(myCache.size * avgItemSize).toFixed(2)} MB`) - 监听
performance.memory（需 HTTPS，Chrome 支持）：定期检查performance.memory.usedJSHeapSize / performance.memory.totalJSHeapSize是否持续 > 0.8，并告警
