weakref用于弱持有图片对象以避免阻止gc，finalizationregistry负责在对象被回收时触发清理回调；二者必须配合使用，单独使用weakref无法自动清理缓存。
WeakRef 不能直接缓存图片对象，必须配合 FinalizationRegistry
浏览器中 Image 实例本身是可被 GC 的，但如果你只是把 new Image() 存进 Map，它就变成强引用，不会自动释放。WeakRef 只能包装对象，不能“自动触发清理逻辑”——它不提供回调。真正负责通知你“对象已被回收”的是 FinalizationRegistry。两者必须配对使用：用 WeakRef 持有图片（避免阻止 GC），用 FinalizationRegistry 注册清理钩子。
常见错误是只用 WeakRef 包一层然后以为完事了，结果缓存项永远不删，内存持续上涨。
- 必须用
FinalizationRegistry的register()方法，传入图片实例、注册键（如 URL）、以及一个 cleanup 回调 -
WeakRef仅用于后续「尝试读取」：调用weakRef.deref()，返回Image或undefined - 注册键（key）建议用字符串 URL，方便在 cleanup 中从缓存 Map 中删除对应项
缓存结构必须分离「弱引用容器」和「元数据索引」
不能把 WeakRef 直接塞进 Map 当 value——因为 deref() 可能返回 undefined，你无法区分“还没加载完成”和“已被回收”。正确做法是用普通 Map 存 URL → { weakRef, status, loadingPromise }，其中 weakRef 是 WeakRef<htmlimageelement></htmlimageelement>，status 记录 'pending' / 'loaded' / 'error'。
这样既能支持懒加载的并发控制（避免重复请求），又能在 deref() 失败时快速 fallback 到重新加载。
- Map 的 key 必须是唯一标识，推荐用完整 URL（含查询参数），避免因 CDN 版本号不同导致缓存错乱
- 不要在
FinalizationRegistry的 cleanup 回调里操作 DOM 或触发重绘，它在非确定时机执行，可能已无上下文 - cleanup 回调里只做 Map 删除 + 可选日志，例如：
cacheMap.delete(key)
加载失败或中断时需手动 unregister，否则 registry 会误报回收
FinalizationRegistry 的注册是单向的：一旦注册，即使你提前销毁了图片（比如用户切页、img.onload 前就 img.src = ''），registry 仍可能在稍后触发 cleanup。这会导致缓存被清掉，但实际图片还在内存里（只是没被 WeakRef 持有），下次访问又得重载。
所以每次图片加载完成（无论成功失败），都应显式调用 registry.unregister(token)，其中 token 是你传给 register() 的第三个参数（通常就是 URL 字符串）。
- 在
img.onload和img.onerror里都加registry.unregister(url) - 如果使用
Fecth + createObjectURL方式加载，记得revokeObjectURL后也unregister - 不 unregister 的后果：缓存 Map 被清空，但图片其实还活着；下一次相同 URL 请求会新建
Image，造成内存碎片
实际使用时要注意 Safari 和旧版 Chrome 的兼容性缺口
WeakRef 和 FinalizationRegistry 在 Safari 14.1+、Chrome 84+ 才稳定可用。Safari 14.0 有 WeakRef 但 FinalizationRegistry 不触发回调；某些安卓 WebView（如 UC 内核）完全不支持。
别用 try/catch 包裹整个逻辑来降级——那样会让降级后的代码（比如用普通 Map + 手动清理）行为不一致。应该先检测全局是否存在，再决定启用哪套策略。
- 检测方式：
typeof WeakRef !== 'undefined' && typeof FinalizationRegistry !== 'undefined' - 降级方案不是“禁用缓存”，而是退回到带 TTL 的 Map 缓存（例如 5 分钟过期），并监听页面 visibilitychange 主动清理
- 尤其注意 SSR 场景：服务端没有这些 API，必须确保初始化逻辑不报错（例如包裹在
if (typeof window !== 'undefined')中）
WeakRef 的“自动回收”不是魔法，它只解决“持有不阻 GC”这一环；真正的缓存生命周期管理，还得靠你设计好注册/注销时机、状态标记、以及降级兜底。最常被忽略的是 unregister —— 很多人写了 registry 却忘了在 error 里调它，结果缓存比不用还耗内存。
