JavaScript 中的 WeakRef 与 FinalizationRegistry：何时才是它们真正的用武之地

更进一步的 FinalizationRegistry，则像是给这把刀加了一个“对象消失后的通知机制”。它允许你在一个对象被垃圾回收后，执行一段自定义的清理逻辑。这听起来更像是一个“析构函数”，但实际上，它在 JavaScript 的语境下有着完全不同的行为逻辑和可靠性预期。理解这两者的核心，不在于记住 API 调用，而在于理解它们与 JavaScript 垃圾回收（GC）机制之间那种微妙且不可靠的“约定”。

WeakRef：不是缓存，而是“可能还在”的观察窗

首先要明确一点：WeakRef 本身不是一个数据容器。你不能遍历它，也不能指望它持久地持有数据。它的唯一作用，是让你获得对一个对象的弱引用，并通过 .deref() 方法尝试取回这个对象。如果对象还在，你就能拿到；如果对象已经被 GC 回收，.deref() 就返回 undefined。

一个常见的误解是试图用 WeakRef 数组来管理一组对象。这行不通，因为数组本身持有对 WeakRef 实例的强引用，而 WeakRef 实例是独立的对象，不会被回收。真正需要的是一个能持有弱引用的集合，这就是 WeakMap 和 WeakSet 存在的意义。因此，WeakRef 通常的搭档是普通的 Map 或 Set，用它们来存储元数据（如键名），而值则用 WeakRef 包裹。

// 一个简单的、可能出问题的缓存示例
const cache = new Map(); // 键 -> WeakRef(值)
const registry = new FinalizationRegistry((key) => {
  console.log(`Key "${key}" 对应的对象已被回收，清理缓存条目。`);
  cache.delete(key);
});

function getCachedData(key) {
  const ref = cache.get(key);
  const obj = ref?.deref();
  if (obj) {
    return obj; // 缓存命中
  }
  // 缓存未命中，创建新对象
  const newObj = computeExpensiveData(key);
  cache.set(key, new WeakRef(newObj));
  registry.register(newObj, key); // 注册清理回调
  return newObj;
}

这个模式看起来合理，但它隐藏了一个关键问题：GC 的时机完全不可预测。缓存条目（Map 中的键）只会在对象被回收、FinalizationRegistry 回调执行后才会被删除。在这之前，Map 会一直积累无效的键，虽然它们对应的 WeakRef 是空的，但这仍然是一种逻辑上的“泄漏”。

FinalizationRegistry：不可靠的、最终的通知

如果说 WeakRef 是“不确定的观察”，那么 FinalizationRegistry 就是“不确定的通知”。规范明确警告开发者：不要依赖清理回调进行任何关键的程序逻辑。原因有很多：

• 执行时机未知：回调可能在对象被回收后很久（几秒、几分钟，甚至更久）才执行，也可能在程序关闭时根本不执行。
• 执行与否未知：JavaScript 引擎没有义务必须调用这些回调。在某些情况下（如进程突然退出），回调会被跳过。
• 顺序和数量未知：无法保证回调的执行顺序，也无法保证一个对象只触发一次回调。

因此，FinalizationRegistry 的正确角色，不是“资源释放器”，而是“资源泄漏的最后一道保险丝”。它的典型使用场景是清理那些由 JavaScript 对象管理、但存在于 JavaScript 堆之外（或引擎内部）的资源。

一个真实世界的场景：管理 Canvas 或 WebGL 资源

假设你在一个图形编辑器中使用 Canvas，每个图形元素对应一个 JavaScript 对象，并且在底层（Canvas 上下文或 WebGL）分配了纹理或缓冲区。当 JavaScript 对象被废弃时，你希望自动释放底层的 GPU 内存。

const textureRegistry = new FinalizationRegistry((textureId) => {
  // 注意：这个回调可能在未来的任何时间点被调用
  gl.deleteTexture(textureId);
  console.warn(`纹理 ${textureId} 通过 FinalizationRegistry 自动清理。`);
});

class GraphicElement {
  constructor(gl, imageData) {
    this.textureId = gl.createTexture();
    // ... 绑定纹理数据 ...
    // 将 this 注册到清理注册表，持有值是 textureId
    textureRegistry.register(this, this.textureId, this);
    // 注意第三个参数（token）用了 this，方便后续手动取消注册
  }

  destroy() {
    // 显式销毁是首选且可靠的方式
    gl.deleteTexture(this.textureId);
    textureRegistry.unregister(this); // 取消注册，避免重复清理
    this.textureId = null;
  }
}

在这个设计中，destroy() 方法是释放资源的主要途径。FinalizationRegistry 只是一个安全网，用于捕获那些因为开发者疏忽（比如忘记调用 destroy）而泄漏的纹理。如果回调被执行了，控制台会输出一个警告，这有助于在开发阶段发现资源管理漏洞。

决策矩阵：什么时候该用，什么时候不该用

基于它们的特性和风险，我们可以总结出以下决策指南：

实战建议与常见陷阱

如果你确定要使用这些 API，请牢记以下几点：

1. Hold Value 不要引用目标对象：这是最常见的错误。如果你在注册时这样写：registry.register(target, target)，那么 hold value（第二个参数）就强引用了 target，导致它永远无法被回收，FinalizationRegistry 完全失效。
2. 总是提供 Unregister Token：在调用 register 时，传入第三个参数（token）。这通常就是目标对象本身。这样，当你显式清理资源时，可以调用 unregister(token) 来移除注册，确保清理回调不会在之后被意外调用。
3. 假设回调永远不会执行：你的程序逻辑必须在没有 FinalizationRegistry 回调的情况下也能正确运行。回调只能做锦上添花或非关键的清理工作。
4. 避免在回调中创建新的强引用：清理回调中应只执行轻量级操作，如记录日志、更新内部计数器或释放纯外部资源。切忌在回调中做可能触发新一轮复杂对象分配的操作。

总结：拥抱不确定性，而非依赖它

WeakRef 和 FinalizationRegistry 是 JavaScript 赋予开发者的底层工具，它们反映了语言与宿主环境（尤其是垃圾回收器）之间复杂的交互关系。它们的价值不在于提供一种可靠的、确定性的生命周期管理模型，而在于为那些无法通过其他方式优雅解决的特定问题，提供了最后的选择。

对于大多数应用层面的业务逻辑，传统的强引用、明确的生命周期管理和基于容量/时间的缓存策略，是更简单、更可预测、也更容易维护的选择。当你开始考虑 WeakRef 时，不妨先问自己：我是否真的无法通过设计来避免这个问题？我是否能承受这个对象“随时消失”的不确定性？

最终，这些 API 的最佳用途，可能恰恰是帮助我们构建那些更健壮、更显式的资源管理抽象层，而不是让每个业务模块都直接面对 GC 的不可预测性。它们是一把好刀，但请确保你是在雕刻一件复杂的艺术品，而不是简单地用它来切水果。