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 只管了其中一层。
