service worker 本身不会因闭包导致内存泄漏，因其运行在独立线程且生命周期受浏览器严格管控；真正风险在于长期持有大型数据、未清理定时器/监听器、滥用 postmessage 或错误处理响应流等资源驻留行为。
Service Worker 本身不支持传统意义上的“闭包导致内存泄漏”这一机制，因为它运行在独立的、无 DOM 的线程中，且生命周期由浏览器严格管控（安装 → 激活 → 等待 → 终止）。它没有全局作用域持久引用、不会保留对页面变量的意外捕获，因此闭包本身不会直接触发 Service Worker 的内存上限预警。
真正需要关注的是“资源驻留型逻辑”误用
开发者常把 Service Worker 当作普通 JS 环境来写，无意中引入了以下几类易被误认为“闭包问题”的高内存风险行为：
- 长期持有大型数据结构：例如在全局作用域缓存一个未分片的 10MB JSON 对象、或维护一个不断增长的 Map/Set（如用于请求去重或状态追踪），即使没显式闭包，也会持续占用内存
- 未清理的事件监听器或定时器：在 activate 或 fetch 事件中注册了 setInterval 或 addEventListener，但未在 service worker 生命周期结束前 clear/移除，导致引用链无法释放
- 滥用 onmessage + 大量 postMessage 数据：主线程频繁发送大体积消息（如 Base64 图片、日志数组），而 Service Worker 未及时 consume 或做了同步解析，造成消息队列堆积和内存滞留
- 错误复用响应流（Response.body）：在 fetch 事件中多次调用 response.body.getReader() 或未正确关闭 ReadableStream，尤其配合 cache.put() 时可能引发底层资源未释放（Chrome 曾有相关内存累积报告）
如何识别这类问题是否正在发生
不能靠代码静态分析“有没有闭包”，而要结合运行时可观测性判断：
- 打开 Chrome DevTools → Application → Service Workers → 勾选 “Update on reload” 和 “Offline”，然后刷新页面
- 在 Sources 面板中找到已注册的 sw.js，右键 → “Add to watch” 观察关键变量（如 caches.keys()、self.__WB_MANIFEST）大小变化
- 使用 Performance 面板录制一段后台活跃期（如触发多次 fetch + cache 操作），重点关注 Memory 栏中的 “JS Heap size” 和 “System memory” 趋势——若持续上升且不回落，说明存在资源滞留
- 在 Console 中执行 self.clients.matchAll().then(c => console.log(c.length))，确认无异常残留 client 引用（虽不直接占内存，但可能掩盖通信逻辑缺陷）
规避建议：用声明式代替命令式管理
Service Worker 的健壮性来自“无状态、短生命周期、事件驱动”。应主动放弃“维持状态”的思维：
- 所有缓存操作优先走 Cache API，而非 in-memory 存储；需临时状态时，用 IndexedDB（有容量配额但可持久化管理），不用全局对象
- 避免在 install/activate 中执行耗时同步操作；fetch 事件内不进行复杂计算或大对象构造，只做路由分发与策略决策
- 如需后台任务（如定时同步），改用 Background Sync API 或 Periodic Sync（需用户授权），而非 setInterval
- 调试阶段启用 chrome://serviceworker-internals 查看每个 SW 实例的内存占用与激活状态，及时发现异常驻留
