JavaScript 中的 WeakRef 与 FinalizationRegistry：什么时候该用它们

很多 JavaScript 开发者第一次接触 WeakRef 和 FinalizationRegistry 是在某个浏览器兼容性表格里，扫一眼就翻过去了。这两个 API 确实特殊，它们直接暴露了垃圾回收（GC）的边角信息，而这种信息在 JavaScript 里通常是被刻意隐藏的。需要理解的是，它们不是用来替代 WeakMap 的，也不是给你做内存优化的常规工具。它们的存在更像是一种兜底机制，用来解决一些用普通强引用无法优雅处理的场景。

在讨论什么时候该用之前，得先搞清楚一个问题：WeakMap 不是已经能处理“对象回收”了吗？为什么还需要 WeakRef？

WeakMap 的局限性：你只能弱引用键，不能弱引用值

WeakMap 的语义是：只要键对象还被外部引用，键值对就存在；一旦键对象被回收，整个键值对就被移除。这非常适合做缓存：你把一些附属数据挂在对象上，又不希望影响对象的生命周期。

但 WeakMap 有一个硬性限制：你只能弱引用“键”，不能弱引用“值”。如果你缓存的值本身是另一个大对象，而这个值没有其他外部引用，它仍然会被保留，直到键被回收。换句话说，WeakMap 的清理时机是绑定在键上的，而不是绑定在值上的。

举个例子，你写了一个根据用户对象缓存其权限列表的函数：

const permissionCache = new WeakMap();

function getPermissions(user) {
  if (!permissionCache.has(user)) {
    permissionCache.set(user, fetchPermissionsFromServer(user));
  }
  return permissionCache.get(user);
}

这个写法看起来没问题，但注意一个细节：当 user 对象已经没有任何外部引用时，WeakMap 会移除整个条目，包括其中的权限列表。可是如果权限列表是一个庞大的嵌套结构，它可能会在内存中驻留一段时间，因为 WeakMap 的清理并不是立即发生的。在极端情况下，权限列表的存活时间会超出你的预期。

这正是 WeakRef 想解决的问题：它让你能够保存一个对象的弱引用，不阻止该对象被回收，同时你还可以尝试通过 deref() 重新获取它。如果对象还活着，你得到它；如果已经被回收，你得到 undefined。

let userRef = new WeakRef(user);
let cached = userRef.deref();

if (cached) {
  console.log(cached.name);
} else {
  console.log('用户已经被回收了');
}

这看起来很像 WeakMap，但区别在于：WeakRef 的目标是“对象本身”，而不是“对象与某个值的关系”。你可以用 WeakRef 去缓存一个值，然后用 FinalizationRegistry 在值被回收时清理相关的依赖资源。

FinalizationRegistry：对象被回收时，你终于能收到通知了

光有 WeakRef 还不够，因为很多时候你不仅想知道对象还活着没有，还想在它被回收后做一些清理工作。比如：

• 释放一个 DOM 节点关联的 WebSocket 连接。
• 从某个注册表里移除已销毁的组件实例。
• 清理一个缓存条目的外部引用，避免形成悬挂引用链。

FinalizationRegistry 提供的就是这个能力。你可以注册一个对象，并传入一个回调函数。当该对象被垃圾回收时，回调会被触发，并收到你预先设定的持有值（holdings）。

const registry = new FinalizationRegistry((heldValue) => {
  console.log('对象已被回收', heldValue);
});

let obj = {};
registry.register(obj, 'some-key');

obj = null;
// 当 GC 运行时，回调会执行，输出 '对象已被回收 some-key'

这里有一个关键点：回调执行时机完全不由你控制。它取决于垃圾回收器的运行策略，可能很快，也可能很久，甚至在程序退出前都不一定会执行。这意味着你绝对不能把 FinalizationRegistry 当作“可靠的资源清理钩子”来使用，它更适合作为一种“尽力而为的补充清理”机制。

真实使用场景：什么样的系统会需要这种“不保证可靠”的机制

既然回调时机不可控，为什么还会有人用？因为在某些场景下，即使时机不可控，也比永远不清理要好。

场景一：长列表中的 DOM 节点状态追踪

在虚拟滚动或大规模 DOM 操作的场景中，你可能会维护一个 Map，用来存储某些 DOM 节点对应的数据状态。比如每个节点是否被选中、是否处于编辑模式。如果节点被移除，但 Map 中的条目还留在那里，就造成了泄漏。用 WeakMap 可以解决部分问题，但你无法在节点被回收时得到通知，也就无法优雅地处理那些依赖节点存在的业务状态。

使用 WeakRef + FinalizationRegistry，你可以在节点被回收时触发一个回调，从状态表中移除对应记录，同时把与节点强绑定的附属状态（比如定时器、事件监听器）一起清理掉。这样做即使清理不完美，也比单纯依靠 WeakMap 的被动清理更主动。

场景二：大型应用中的组件实例缓存

想象一个编辑器应用，你根据文档中的某个段落对象缓存对应的渲染引擎实例。你希望：当段落对象还活着时，复用渲染引擎；当段落对象被回收时，渲染引擎也能被回收。这恰好是 WeakRef 的典型用法。

const engineCache = new Map();
const engineRegistry = new FinalizationRegistry((paragraphId) => {
  engineCache.delete(paragraphId);
});

function getRenderer(paragraph) {
  const ref = engineCache.get(paragraph);
  if (ref) {
    const engine = ref.deref();
    if (engine) return engine;
  }
  const engine = new Renderer(paragraph);
  engineCache.set(paragraph, new WeakRef(engine));
  engineRegistry.register(engine, paragraph.id);
  return engine;
}

这段代码的逻辑很典型：用 Map 保存段落对象到渲染引擎弱引用的映射，用 FinalizationRegistry 监听渲染引擎的回收，然后从 Map 中移除对应的条目。这样既不会阻止渲染引擎被回收，也不会让 Map 中残留大量已经失效的引用。

但注意，这里有一个微妙的问题：如果段落对象已经被回收，而渲染引擎还没有被回收，那么 Map 中仍然会有条目，直到引擎被 GC。这个窗口期是不可避免的。如果业务逻辑对这种情况很敏感，你可能还需要在 deref() 返回 undefined 时主动删除条目。

场景三：异步任务中的上下文清理

在一些框架实现里，开发者会用 WeakRef 来跟踪那些“即将过期的”异步任务上下文。比如在 Web Worker 中，你创建一个后台任务，任务上下文对象可能很快就不再被主线程引用，但你希望在主线程上下文消失后，能自动取消相关请求。FinalizationRegistry 可以用来监听上下文对象的回收，然后触发清理逻辑。

这类场景的特点是：清理动作本身不是关键路径，即使偶尔漏掉，系统也不会崩溃，但长期累积下来会形成资源浪费。所以用 FinalizationRegistry 做兜底是合理的。

最容易踩的几个坑：为什么大家不推荐日常使用

说实话，这两个 API 在日常业务开发中并不常用，因为它们有几个硬伤：

第一，你无法预测 GC 时机。 即使你调用了 deref()，对象也未必立即被回收。现代 JS 引擎的 GC 是分代、增量、并发的，一个对象可能在被 WeakRef 引用的情况下仍然存活很长时间。反过来，即使你没有强引用它，它也可能因为 GC 没来得及运行而一直存在。所以你不能用 WeakRef 做任何“保证释放”的逻辑。

第二，FinalizationRegistry 的回调不能依赖当前上下文。 回调可能会在非常晚的时候执行，甚至在你的应用已经切到后台后才执行。如果你在回调里访问 DOM 元素，可能那个 DOM 元素早就被移除了。回调里只能做一些纯粹的数据清理，不能做复杂的 UI 操作。

第三，过度使用会影响 GC 效率。 这一点容易被忽略。FinalizationRegistry 本身需要引擎维护额外的数据结构来跟踪对象状态，大量的注册和注销操作会增加 GC 的负担。如果你在热路径上频繁注册和注销对象，可能得不偿失。

方案对比：WeakRef + FinalizationRegistry 与其他内存管理手段

选择哪种方案，取决于你的核心诉求是“缓存复用”“自动清理”还是“精确控制”。

从这张表可以看出，WeakRef 和 FinalizationRegistry 并不是用来替代 WeakMap 的，而是用来解决 WeakMap 解决不了的问题：当你需要弱引用一个值对象，并且在它被回收后执行额外的清理操作时，它们才是合适的选择。

什么时候不该用：识别被误解的“内存优化”需求

很多团队遇到内存问题时，第一反应是“用 WeakRef 优化”。这通常不是好主意。

如果你遇到的问题是：某个对象被长期持有，导致内存占用持续上涨，最应该做的是找出为什么会被持有。比如事件监听器没有被移除、定时器没有清除、闭包捕获了大对象。这些都是强引用问题，用 WeakRef 掩盖反而会让问题更难排查。WeakRef 适合的场景是：你希望“在对象还活着时引用它，在对象消失后自动失效”，而不是“让对象更快被回收”。

还有一个常见误区是把 FinalizationRegistry 当成析构函数（destructor）。在一些语言里，对象销毁时有确定性的清理逻辑。JavaScript 里没有这种保证。FinalizationRegistry 的回调可能永远不执行，尤其当浏览器标签页被切到后台时，GC 可能被延迟甚至挂起。如果你把关键的清理逻辑放在里面，比如关闭文件句柄或提交事务，一旦回调没执行，就会导致严重故障。

一个更务实的判断标准是：如果你发现自己在代码里频繁调用 deref() 并处理 undefined 分支，这说明你的业务逻辑正在依赖“对象是否还活着”这一事实。那应该重新审视设计——是否有更简单的方案？

如何安全地使用：一条务实的落地路径

如果你真的遇到了适合 WeakRef 的场景，我建议你按照以下步骤推进：

• 第一步，先用 WeakMap 实现基本功能，确认它无法满足需求后再考虑 WeakRef。因为 WeakMap 的语义更清晰，也不需要处理回调时机。
• 第二步，把 WeakRef 限制在模块内部。不要把它作为公共 API 暴露给外部调用者，因为外部调用者很难理解“这个对象可能突然不存在”的语义。
• 第三步，为 FinalizationRegistry 回调设计一个超时或兜底机制。比如在回调中只做幂等清理，并允许重复执行。
• 第四步，在测试中显式触发 GC。浏览器支持通过 –js-flags=”–expose-gc” 或 DevTools 的 Memory 面板来观察对象回收情况。你至少应该确认：在极端情况下，清理逻辑不会导致程序崩溃。

下面是一个更完整的实战示例，组合了 WeakRef 和 FinalizationRegistry 来处理缓存场景：

const cache = new Map();
const registry = new FinalizationRegistry((key) => {
  const ref = cache.get(key);
  if (ref && !ref.deref()) {
    cache.delete(key);
  }
});

function getObject(key) {
  let ref = cache.get(key);
  if (ref) {
    let obj = ref.deref();
    if (obj) return obj;
  }
  let obj = { data: key };
  cache.set(key, new WeakRef(obj));
  registry.register(obj, key);
  return obj;
}

注意这里的回调中，我通过 cache.get(key) 再次检查 deref() 的结果，避免在缓存已经更新的情况下误删新条目。这是因为 FinalizationRegistry 的回调是基于对象身份的，但缓存的键可能被重新赋值。如果你不检查，可能会出现“旧对象被回收，回调删除了新对象”的竞争问题。

这种竞争问题在实际工程中非常隐蔽，也是我建议尽量少用这些 API 的原因之一。

总结：它们是最后的工具，不是常规的武器

WeakRef 和 FinalizationRegistry 是 JavaScript 语言中少见的与 GC 直接交互的 API。它们解决的是真实存在的问题，但不是大多数业务系统会遇到的问题。如果你正在写框架、底层库、编辑器或涉及大量 DOM 节点与缓存交互的复杂应用，它们会派上用场。但如果你只是在普通的业务代码中寻找一种“让内存更安全”的方式，更可能的结果是引入更多不确定性。

理解它们的关键不在于记住 API 签名，而在于理解 JavaScript 的垃圾回收模型：强引用是常态，弱引用是特例，而 FinalizationRegistry 只是给你一个“尽力而为”的通知。做好这种心理预期，你才能在合适的场景中做出正确的选择。