全局缓存无限增长导致内存崩溃，本质是缓存对象长期被强引用、无淘汰机制、不随业务生命周期释放。需通过DevTools堆快照对比定位持续增长的缓存实例，用LRU、过期时间、WeakMap或生命周期钩子修复，确保缓存有边界、有寿命、可主动断开。
全局缓存无限增长导致内存崩溃，本质是缓存对象长期被强引用、无淘汰机制、不随业务生命周期释放，最终撑爆 JS 堆。它不会立刻报错，但页面运行越久、用户操作越频繁，内存占用越不可控——比如中后台系统挂一晚涨到 2GB，可视化大屏三天必刷新“续命”。排查关键不是看“用了多少”，而是确认“该删的删没删”。
先定位：用 Chrome DevTools 看清缓存是否真在增长
打开 Memory 面板，按顺序操作：
- 点小垃圾箱图标（Collect garbage）手动触发 GC，再拍第一个堆快照（Snapshot 1）
- 执行几次典型操作（如反复进入/退出一个列表页、刷新数据表格）
- 再次 GC → 拍第二个快照（Snapshot 2），重复一次得 Snapshot 3
- 选 Snapshot 3 → 切 Comparison 视图 → 对比 Snapshot 1，重点关注 Delta 列中持续增加的项
- 筛选 (closure)、Object、Array、你自定义的缓存类名（如 ApiCache 或 userStore）
重点查这三类全局缓存模式
以下写法在真实项目中高频引发泄漏：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- window.cache = {} 或 globalThis.dataPool = new Map()：未加限制，每次 set 都累加，永不清理
- const cache = {} 写在模块顶层，被多个函数闭包引用，且没有 clear 接口
- 用普通 Map / Object 缓存 DOM 节点或响应体（如 cache.set(id, res.data)），key 是字符串、value 是万级数组或完整 JSON，又没设大小上限
修复：让缓存有边界、有寿命、可主动断开
不是禁用缓存，而是管住它的生命周期：
立即学习“Java免费学习笔记（深入）”；
- 加数量或内存上限：比如 Map 缓存超过 100 条就 delete map.keys().next().value（LRU 简化版）
- 设过期时间：给每条缓存加 expiresAt: Date.now() + 5 * 60 * 1000，读取前检查并自动剔除
- 改用弱引用结构：DOM 关联数据用 WeakMap（key 必须是 element），避免节点移除后缓存还锁着它
- 绑定业务生命周期：在路由离开、组件卸载时调用 cache.clear() 或 resetCache()，别只靠“下次覆盖”
- 上线前剥离调试缓存：删掉 console.log(cache) 或 debugger，它们会让 V8 保留整个作用域链
验证是否修好了
不能只看一次快照，要跑回归验证：
- 在 Performance 面板开启内存录制，连续操作 5–10 次，观察 JS Heap 曲线是否趋于平稳（不再阶梯式上升）
- 回到 Memory 面板，拍三个快照后对比，确认你修复的缓存构造函数 Delta 回落到 ±0
- 用 performance.memory 在控制台手动检查：执行 cache.clear() 后，performance.memory.usedJSHeapSize 应明显下降
