WeakRef 单独无法支撑图像资源池，因其仅提供“可能还活着”的引用通道，不通知回收时机；必须搭配 FinalizationRegistry 才能触发自动清理，否则缓存条目堆积、deref() 频繁返回 undefined 导致重复加载与内存泄漏。
WeakRef 本身不能直接实现资源池，必须搭配 FinalizationRegistry 才能触发自动清理；单独用 WeakRef 只是“存得住但取不出”，容易误以为缓存生效了，实际 weakRef.deref() 返回 undefined 时已失效。
为什么 WeakRef 单独无法支撑图像资源池
WeakRef 的核心限制在于：它只提供一个“可能还活着”的引用通道，不保证对象存在，也不通知你何时消失。图像组件高频切换时，若仅靠 weakRef.deref() 判断，会频繁遇到 undefined，导致重复解码、渲染卡顿，且无法及时从池中剔除无效条目。
常见错误现象：
- 缓存命中率看似高，但
deref()总返回undefined，图像反复加载 - 池中
WeakRef对象越积越多，Map内存持续增长（因为没清理键） - DOM 节点已被移除，但关联的图像数据仍滞留在池里
必须绑定 FinalizationRegistry 实现“回收即清理”
FinalizationRegistry 是唯一能在 GC 回收弱引用目标后，**主动通知你并执行清理逻辑**的机制。它不是轮询，不阻塞主线程，是真正响应式的释放入口。
实操要点：
- 注册时传入的
heldValue必须是能唯一标识缓存项的值（如字符串 key 或 symbol），不能是对象本身 - 回调函数内只能做轻量清理（如
cache.delete(key)），禁止再访问已回收对象或触发重计算 - 注册必须在
WeakRef创建后立即进行，否则 GC 可能在注册前就完成回收，导致漏删 - 避免在回调中抛错，否则该 registry 后续注册项可能静默失效
示例关键片段：
const cache = new Map();
const registry = new FinalizationRegistry(key => {
cache.delete(key); // 安全：只操作 cache 和 key
});
function setCache(key, image) {
const weakRef = new WeakRef(image);
cache.set(key, weakRef);
registry.register(image, key, weakRef); // 第二参数是 heldValue，第三是可选 token
}
图像资源池需额外处理的边界场景
图像对象（HTMLImageElement、ImageBitmap、OffscreenCanvas）有其特殊性，不能只依赖弱引用机制：
-
HTMLImageElement加载失败时（onerror）需手动cache.delete(key)，否则弱引用永远不触发回收 -
ImageBitmap不支持直接register（部分浏览器报错），应包装为普通对象再注册 - 若图像被多个组件共享，需计数器或引用标记，否则首个组件卸载就清掉，其他组件立刻失效
- SSR 或服务端环境无
WeakRef/FinalizationRegistry，必须降级为普通 Map + 显式生命周期钩子（如componentWillUnmount）
性能与兼容性必须验证的三点
这个方案不是“设了就完事”，上线前必须确认：
- Chrome 84+/Firefox 79+/Safari 16.4+ 支持完整 API；iOS Safari 16.4 之前版本无
FinalizationRegistry，需 feature detect 并 fallback - GC 触发时机不可控，短时间高频创建/销毁图像时，registry 回调可能延迟几十到几百毫秒，池中残留条目属正常现象
- 大量
WeakRef实例本身有轻微内存开销（每个约 24 字节），池容量建议控制在 50–200 以内，超出后考虑 LRU + 弱引用混合策略
最易被忽略的一点：registry 回调里的 cache.delete(key) 看似简单，但如果 key 是对象或 Symbol，而你注册时传的是字符串，就会完全对不上——键必须严格一致，且推荐用字符串或数字，避开引用类型作为键。
