WeakRef 与 FinalizationRegistry 资源管理技巧

本文深入解析了 JavaScript 中 WeakRef 与 FinalizationRegistry 协同实现高效、安全资源缓存的关键原理：WeakRef 仅用于“松开引用”避免阻止垃圾回收，绝不自动清理缓存条目；而 FinalizationRegistry 才是唯一能在对象被真正回收后精准触发清理（如删除缓存键）的可靠机制——二者职责分明、缺一不可。文章戳破常见误区，强调必须每次写入时同步完成“创建 WeakRef→存入 Map→用该 WeakRef 作为 token 注册 registry”，并提醒读取时务必通过 deref() 主动校验有效性，辅以元数据封装提升健壮性，帮你避开内存泄漏和缓存失效陷阱，写出真正可持续运行的高性能缓存逻辑。

关键不是让 WeakRef “自动清缓存”，而是用它避免强持有，再靠 FinalizationRegistry 在对象真正消失后手动删键——两者分工明确，缺一不可。

WeakRef 只负责“放手”，不负责“擦桌子”

WeakRef 的唯一作用是：不阻止目标对象被 GC。它本身是个普通 JS 对象，只要你把它存进 Map、数组或闭包里，它就一直占内存；而一旦目标被回收，deref() 就返回 undefined，但缓存结构里那个 WeakRef 实例还在，只是成了“空壳”。长期运行后，缓存表里堆满无效条目，查找变慢、内存反升。

所以不能指望 WeakRef 自己清理缓存项。它只解决“能不能收走”，不解决“要不要删掉”。

FinalizationRegistry 是唯一能感知“已回收”的钩子

FinalizationRegistry 的回调不是“快死了来提醒”，而是“已经没了，你赶紧收尾”。它和 WeakRef 是搭档，不是替代：

• 注册时传的 heldValue（比如缓存 key）必须是 string 或 symbol——用普通对象作 key 会导致无法匹配、清理失败
• 回调函数里绝对不能访问原对象，只能做副作用操作，例如 cache.delete(key)
• 必须在创建 WeakRef 后立即调用 registry.register(target, key, weakRef)，且把 weakRef 当作 unregisterToken 传入，否则后续无法精准注销，容易重复触发或漏触发
• 回调执行时机不确定，可能延迟几秒甚至更久，不能用于实时逻辑

缓存结构要拆开“存引用”和“清元数据”

典型错误是把 registry.register() 放在 set() 外面，或复用 registry 却没传对 token。正确做法是每次写入都同步完成三件事：

• 用 new WeakRef(value) 包裹资源对象
• 把 key → weakRef 存进缓存 Map
• 立刻调用 registry.register(value, key, weakRef) —— 这里的 weakRef 是注销凭证，确保将来能取消该注册

示例：

读取时必须容忍 deref() 返回 undefined

get 操作不能直接信任缓存值。必须先调用 ref.deref()，检查是否为有效对象：

• 若返回对象，说明还活着，可直接使用
• 若返回 undefined，说明已被 GC，应触发重建或重新加载逻辑
• 不要把 WeakRef 直接当 value 塞进 Map 后就不管——你无法区分“还没加载完”和“已被回收”

更稳妥的做法是缓存元数据对象，例如：
{ weakRef: new WeakRef(img), status: 'loaded', url }，这样既能支持懒加载控制，也能安全 fallback。

本篇关于《WeakRef 与 FinalizationRegistry 资源管理技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！