如何利用 WeakRef 实现具备自动清理能力的 LRU 算法优化图片缓存内存

WeakRef 不能自动清理缓存，需配合 FinalizationRegistry 主动删除失效项；缓存值应为弱引用，键用普通 Map 管理，Blob/ImageBitmap 需显式释放。

WeakRef 本身不实现 LRU，也不能自动清理缓存条目——它只保证“不阻止 GC”，但失效的 WeakRef 会一直留在你的 Map 里，直到你手动 deref() 检查或用 FinalizationRegistry 主动监听对象销毁。直接拿 WeakRef 套个链表，不做清理闭环，缓存会越跑越慢、越占越多。

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

常见错误是：把 new WeakRef(value) 存进一个按访问顺序排列的数组或 Map，然后以为“对象一回收，缓存就干净了”。实际不是：

• WeakRef.deref() 返回 undefined 后，该 WeakRef 实例仍占据内存，且你的 LRU 结构（比如数组索引、Map 键）还强引用着它
• 没有外部触发机制时，你根本不知道哪个 WeakRef 已失效，只能靠定时轮询 deref() ——这对图片缓存这种高频读写场景是性能毒药
• 如果某张图片被 UI 组件强引用着（比如还在 <img> 标签里显示），它就不会被 GC，对应缓存项也不会释放，哪怕你已滚动出视图

必须搭配 FinalizationRegistry 才算闭环

注册时机和参数稍错，FinalizationRegistry 就形同虚设。关键实操点：

• 每次 set(key, value) 时，立刻调用 registry.register(value, key, weakRef) ——第三个参数 weakRef 是注销 token，漏传会导致重复回调或无法注销
• 回调函数里只做一件事：metadataMap.delete(key)，别碰 weakRef.deref()，也别发请求、改 DOM、写日志
• 注册键 key 必须是可比较的原始值（string 或 symbol），不能是对象，否则 delete 失败
• 不要在回调里尝试重建缓存或触发重加载——GC 回调无执行保障，可能被跳过、延迟数秒甚至永不触发

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

有人想用 WeakMap 当主缓存，省事。行不通：

• WeakMap 只接受对象作键，而图片缓存的 key 通常是 URL 字符串，得包装成对象，反而引入额外引用和 GC 压力
• WeakMap 不支持遍历、size 查询、LRU 排序，你没法知道谁最久没用、谁该淘汰
• 真正要弱化的，是缓存的 值（图片数据或 Blob），不是键；所以得用普通 Map 存元数据（key → { lastAccess, hitCount, ref: WeakRef }），再靠 FinalizationRegistry 清理失效项

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

浏览器中图片资源常以 Blob 或 ImageBitmap 形式缓存，它们的 GC 行为比普通对象更隐蔽：

• Blob 被 URL.createObjectURL() 引用时，即使没其他 JS 引用，也不会被 GC；必须显式调用 URL.revokeObjectURL()
• ImageBitmap 的释放依赖 close() 方法，不调就一直占显存；WeakRef 对它无效，因为 close() 是显式资源管理，不是 GC 能介入的范围
• 如果你缓存的是 HTMLImageElement，注意它自带 src 属性强引用，得先 el.src = '' 再丢弃，否则 WeakRef 永远不会失效

真正难的不是写 LRU 链表，而是让“缓存条目生命周期”和“图片资源真实存活状态”对齐——这需要同时处理 JS 引用、DOM 引用、URL 对象引用、GPU 显存四层关系，WeakRef 只管了其中一层。