WeakRef 结合 LRU 算法自动清理优化图片缓存内存

在优化前端图片缓存时，WeakRef 常被视为实现自动清理的“银弹”。但这里有个关键认知需要先摆出来：WeakRef 本身并不能自动清理缓存，它仅仅提供了一个“不阻止垃圾回收（GC）”的弱引用机制。如果只是简单地将 WeakRef 套进一个手写的 LRU 链表，而不建立完整的清理闭环，结果往往是缓存越跑越慢，内存占用只增不减。

为什么？因为一个失效的 WeakRef 会一直留在你的数据结构里，直到你手动去检查它。要实现真正的“自动”，必须引入 FinalizationRegistry 来监听对象的销毁事件，并主动删除对应的缓存条目。同时，对于 Blob 或 ImageBitmap 这类特殊资源，还需要额外的显式释放操作。

为什么 WeakRef + 手写 LRU 链表 ≠ 自动清理缓存

一个常见的误区是，开发者将 new WeakRef(value) 存入一个按访问顺序排列的数组或 Map 后，就认为万事大吉，觉得“对象一旦被回收，缓存条目就自动消失了”。

现实可没这么简单。这里有几个关键点被忽略了：

• 首先，即使 WeakRef.deref() 返回了 undefined，表示其引用的对象已被回收，但这个 WeakRef 实例本身仍然占据着内存。更重要的是，你的 LRU 结构（无论是数组索引还是 Map 的键）依然在强引用着这个 WeakRef 实例。
• 其次，如果没有外部的触发机制，你根本无法知道哪个 WeakRef 已经失效。唯一的办法是定时轮询所有条目，逐个调用 deref() 进行检查。对于图片缓存这种高频读写的场景，这种轮询无异于性能毒药。
• 最后，还有一个隐蔽的陷阱：如果某张图片正被 UI 组件强引用（比如还在一个 标签里显示），那么即使它早已滚动出视图，GC 也不会回收它，对应的缓存项也就永远无法释放。

所以你看，光有 WeakRef 和 LRU 逻辑，只是搭了个架子，离“自动清理”还差最关键的一环——如何及时获知对象已死并清理其“墓碑”。

必须搭配 FinalizationRegistry 才算闭环

这最关键的一环，就是 FinalizationRegistry。它的作用是在注册的对象被垃圾回收时，执行你预设的回调函数。但用起来有不少细节，注册时机和参数稍有差错，它就可能形同虚设。

几个实操关键点：

• 注册时机要精准：在缓存 set(key, value) 时，就应该立刻调用 registry.register(value, key, weakRef)。这里第三个参数 weakRef 是注销时用的 token，如果漏传，可能导致重复回调或无法注销。
• 回调函数要纯粹：回调函数里最好只做一件事：metadataMap.delete(key)。不要在里面尝试调用 weakRef.deref()（此时对象已不存在），也不要执行发起网络请求、修改 DOM、写入日志等副作用大的操作。因为 GC 回调的执行时机和次数都没有保证。
• 注册键要可靠：注册时传入的 key 必须是可比较的原始值，比如字符串或 Symbol。如果传入对象，后续在回调里就可能无法正确执行 delete 操作。
• 不要依赖回调重建：切忌在回调函数里尝试重建缓存或触发资源重加载。GC 回调可能被延迟数秒，甚至在某些情况下被浏览器完全跳过，依赖它来做业务逻辑是不可靠的。

这样一来，当缓存的值（如图片对象）被 GC 回收后，FinalizationRegistry 会通知你，你就能立刻清理掉 Map 中对应的键和那个已经无用的 WeakRef 实例，形成一个完整的清理闭环。

WeakMap 在这里只是“辅助验证”，不是缓存主体

既然提到了弱引用，可能有人会想：直接用 WeakMap 当缓存容器不是更省事吗？答案是否定的，至少在图片缓存这个场景下，WeakMap 很难担当主力。

原因有三：

• 键类型限制：WeakMap 只接受对象作为键。而图片缓存的键（Key）通常是 URL 字符串。为了使用 WeakMap，你不得不把字符串包装成对象，这反而引入了额外的引用和 GC 压力，与优化初衷背道而驰。
• 功能缺失：WeakMap 不支持遍历、没有 size 属性，更无法实现 LRU 算法所需的排序功能。你根本无法知道哪些条目最久未被访问，也就无从执行淘汰策略。
• 弱化目标错位：在缓存设计中，我们真正希望被弱化的是缓存的值（即图片数据、Blob 等大内存对象），而不是键。因此，更合理的架构是使用一个普通的 Map 来管理元数据（例如 key → { lastAccess, hitCount, ref: WeakRef }），再利用 FinalizationRegistry 来清理那些值已被回收的条目。WeakMap 或许可以用来做一些辅助性的验证或关联，但它不适合作为缓存的主数据结构。

图片缓存的特殊坑：Blob 和 ImageBitmap 生命周期难控

前端图片缓存还会遇到一些更棘手的“钉子户”，主要是 Blob 和 ImageBitmap。它们的生命周期不完全由 JS 的 GC 管理，行为更加隐蔽。

• Blob 的 URL 劫持：一个 Blob 对象一旦通过 URL.createObjectURL() 创建了 URL，即使它在 JavaScript 中已经没有其他引用了，只要这个 URL 还没被撤销（revoke），Blob 就不会被 GC 回收。因此，必须显式调用 URL.revokeObjectURL() 来释放它。
• ImageBitmap 的显式释放：ImageBitmap 直接关联 GPU 显存，它的释放依赖于显式调用 close() 方法。如果不调用，显存就会一直被占用。WeakRef 对它是无效的，因为资源的释放是显式管理逻辑，不在常规 GC 的管辖范围内。
• HTMLImageElement 的自带引用：如果你缓存的是 HTMLImageElement DOM 对象，需要注意它的 src 属性会强引用图片数据。在决定丢弃该元素前，必须先设置 el.src = ''，否则 WeakRef 会永远认为它有效。

说到底，实现一个 LRU 链表逻辑并不算最难的部分。真正的挑战在于如何让“缓存条目的生命周期”与“图片资源真实的存活状态”精确对齐。这要求开发者同时处理好 JavaScript 引用、DOM 引用、URL 对象引用乃至 GPU 显存管理这至少四层关系。而 WeakRef 和 FinalizationRegistry，只是帮我们管好了其中 JavaScript 引用这一层而已。