javascript中不存在原生“离线缓存”，所谓泄漏多为service worker缓存、dom引用未释放或localstorage/indexeddb数据滞留；应通过devtools快照对比、清理旧缓存、解绑监听器及添加ttl策略来排查与治理。
JavaScript 中并不存在“离线缓存”这一原生概念——你提到的很可能是 Service Worker 缓存、Cache API 存储的数据，或误将 localStorage / IndexedDB 中长期未清理的数据、DOM 节点引用未释放导致的内存泄漏混称为“离线缓存”。真正的内存泄漏排查，核心在于识别“本该被回收却仍被持有引用”的对象。下面分三类常见场景说明如何检测与清理：
检查 Service Worker 的 Cache API 缓存
Service Worker 使用 cache.put() 或 cache.addAll() 写入的资源会持久保留在磁盘，不随页面关闭而消失，容易堆积过期/冗余缓存。
- 在 Chrome DevTools 中打开 Application → Cache Storage，查看所有已注册的缓存名（如
v1-static、precache-v2），手动点击“Delete”可临时清理 - 在 Service Worker 脚本中主动清理旧缓存：监听
activate事件，用self.caches.keys().then(keys => ...)获取全部缓存名，比对版本号，删除非当前版本的缓存 - 避免缓存动态生成的 URL（如带时间戳或随机参数的请求），这类缓存极易失控且无法复用
排查 DOM 引用导致的“伪离线缓存”泄漏
所谓“遗留在内存中的离线缓存”，很多时候其实是已从 DOM 移除但 JS 仍持有引用的节点（比如全局变量保存了某个 document.getElementById('xxx')，或事件监听器未解绑），造成整个子树无法 GC。
- 使用 Chrome DevTools 的 Memory → Take Heap Snapshot，切换到不同状态（如打开页、操作后、关闭页），对比快照中
Detached DOM tree的数量和大小 - 筛选
HTMLDivElement、Text等类型，查看 retainers（保留路径），确认是否被闭包、事件监听器、全局数组等意外持有 - 清理方式：移除无用的全局引用；使用
element.removeEventListener()解绑监听器；对动态创建的组件，确保在销毁时清空内部缓存 Map/Set、取消定时器、断开 MutationObserver
审查 localStorage / IndexedDB 中的长期数据
这些存储机制本身不属于 JavaScript 堆内存，但若应用逻辑依赖它们做“本地缓存”，且未设计过期策略或清理入口，就会形成事实上的“离线数据滞留”。
- 在 DevTools 的 Application → Local Storage / IndexedDB 中查看键值大小与内容，识别明显过期或重复的数据项（如
cache_user_profile_123_v1、temp_search_result_20230501） - 为缓存添加时间戳和 TTL 字段，在读取时校验有效期；定期调用
localStorage.removeItem(key)或 IndexedDB 的delete()清理 - 避免直接缓存大型对象（如整个响应 JSON），优先缓存 ID + 服务端 TTL 控制，减少客户端负担
真正影响运行时内存的是 JS 堆中无法回收的对象，而非持久化存储本身。关键是区分“缓存机制”和“内存泄漏”：前者是设计选择，后者是引用管理失误。定位靠快照对比，清理靠及时解引、按需清除、版本化控制。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
