WeakRef用于弱持有图片对象以避免阻止GC,FinalizationRegistry负责在对象被回收时触发清理回调;二者必须配合使用,单独使用WeakRef无法自动清理缓存。
浏览器中 Image 实例本身是可被 GC 的,但如果你只是把 new Image() 存进 Map,它就变成强引用,不会自动释放。WeakRef 只能包装对象,不能“自动触发清理逻辑”——它不提供回调。真正负责通知你“对象已被回收”的是 FinalizationRegistry。两者必须配对使用:用 WeakRef 持有图片(避免阻止 GC),用 FinalizationRegistry 注册清理钩子。
常见错误是只用 WeakRef 包一层然后以为完事了,结果缓存项永远不删,内存持续上涨。
FinalizationRegistry 的 register() 方法,传入图片实例、注册键(如 URL)、以及一个 cleanup 回调WeakRef 仅用于后续「尝试读取」:调用 weakRef.deref(),返回 Image 或 undefined
不能把 WeakRef 直接塞进 Map 当 value——因为 deref() 可能返回 undefined,你无法区分“还没加载完成”和“已被回收”。正确做法是用普通 Map 存 URL → { weakRef, status, loadingPromise },其中 weakRef 是 WeakRef<HTMLImageElement>,status 记录 'pending' / 'loaded' / 'error'。
这样既能支持懒加载的并发控制(避免重复请求),又能在 deref() 失败时快速 fallback 到重新加载。
FinalizationRegistry 的 cleanup 回调里操作 DOM 或触发重绘,它在非确定时机执行,可能已无上下文cacheMap.delete(key)
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
Image,造成内存碎片WeakRef 和 FinalizationRegistry 在 Safari 14.1+、Chrome 84+ 才稳定可用。Safari 14.0 有 WeakRef 但 FinalizationRegistry 不触发回调;某些安卓 WebView(如 UC 内核)完全不支持。
别用 try/catch 包裹整个逻辑来降级——那样会让降级后的代码(比如用普通 Map + 手动清理)行为不一致。应该先检测全局是否存在,再决定启用哪套策略。
typeof WeakRef !== 'undefined' && typeof FinalizationRegistry !== 'undefined'
if (typeof window !== 'undefined') 中)WeakRef 的“自动回收”不是魔法,它只解决“持有不阻 GC”这一环;真正的缓存生命周期管理,还得靠你设计好注册/注销时机、状态标记、以及降级兜底。最常被忽略的是 unregister —— 很多人写了 registry 却忘了在 error 里调它,结果缓存比不用还耗内存。