JavaScript中全局缓存无限制增长本质是对象持续被引用而无法被GC回收，导致内存泄漏；需通过代码审查识别window/globalThis挂载、模块顶层闭包等缓存载体，并用Chrome DevTools堆快照对比+Retainers分析定位引用链，结合容量限制、淘汰策略与明确销毁时机修复。
JavaScript 中全局缓存数据无限制增长，本质是对象持续被引用而无法被垃圾回收（GC），最终导致内存泄漏。排查核心在于：确认哪些缓存对象没被释放、谁在持有着它们的引用、以及缓存策略是否缺失清理机制。
定位异常增长的缓存变量
先从代码中识别常见的“全局缓存”载体：
-
window 或 globalThis 上挂载的对象（如
window.cacheMap = new Map()） -
模块顶层的闭包变量（尤其在工具类、SDK 初始化时声明的
const cache = new WeakMap()或Map） -
事件监听器中意外捕获的大数据引用（比如在
addEventListener回调里把整个响应结果存进外部数组） -
定时器或 Promise 链中长期存活的闭包（如
setInterval(() => { data.push(...); }, 1000)不清理）
建议在关键缓存初始化处加注释标记用途和预期生命周期，例如：// 缓存用户会话数据，登出时 clear()。
用 Chrome DevTools 检查内存快照对比
打开 Memory 面板 → 选择 "Heap snapshot" → 拍摄快照，重复操作（如触发缓存写入、切换页面、返回）后拍多张快照：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 切换到 "Comparison" 视图，对比两次快照，筛选 Constructor 列中数量明显上升的类型（如
Object、Array、自定义类名） - 点开某类实例，右侧 "Retainers" 树状图显示谁引用了它；重点看是否通过
window、globalThis、长生命周期对象（如document、单例类实例）间接持有 - 搜索关键词如
cache、map、store，快速定位疑似缓存对象
验证引用链与修复缓存逻辑
找到可疑缓存对象后，检查其引用路径是否合理：
- 如果发现
CacheManager → window → cacheMap → 大量未清理的 response 数据，说明缺少主动清理入口 - 若缓存使用
Map但 key 是普通对象（非原始值），注意 key 本身若被其他地方引用，会导致整个 entry 无法被 GC —— 改用WeakMap（仅适用于对象 key）或确保 key 可被释放 - 为缓存添加容量限制与淘汰策略，例如：
class BoundedCache {
constructor(maxSize = 100) {
this.map = new Map();
this.maxSize = maxSize;
}
set(key, value) {
if (this.map.size >= this.maxSize) {
const firstKey = this.map.keys().next().value;
this.map.delete(firstKey); // 或按 LRU 逻辑删最久未用项
}
this.map.set(key, value);
}
}
监控与预防：运行时内存水位告警
上线前加入轻量级内存监控（仅开发/测试环境启用）：
- 用
performance.memory（Chrome）获取已使用 JS 堆大小：performance.memory.usedJSHeapSize / performance.memory.totalJSHeapSize - 在关键缓存操作后打点，记录缓存 size 和内存占比变化，超过阈值（如 70%）打印 warning
- 配合自动化测试，在模拟高频缓存读写后断言
cache.size是否回归预期值
不复杂但容易忽略：所有全局缓存都应有明确的销毁时机（如组件卸载、页面离开、用户登出），并提供 .clear() 或 .destroy() 方法主动释放。
