FinalizationRegistry 无法精确监控对象被回收的时刻，仅在对象脱离强引用、GC执行后且环境未关闭时异步触发回调；需全局持有注册器，适用于开发诊断与非关键日志，不可用于资源同步释放或精确计时。
FinalizationRegistry 不能精确监控“对象被垃圾回收的真实时刻”，它只在对象被回收后、内存真正释放前的某个不确定时间点触发回调。这是由 JavaScript 垃圾回收机制决定的——GC 时机不可预测，且 FinalizationRegistry 的回调本身不保证立即执行，甚至可能永不执行（例如页面卸载时）。
理解 FinalizationRegistry 的触发前提
注册的回调仅在以下条件全部满足时才可能被调用：
- 目标对象已脱离所有强引用链（即成为 GC 可回收对象）
- V8（或其他引擎）实际执行了回收该对象的 GC 周期
- 引擎在回收后、清理资源前，调度并执行了对应的 finalization 回调
- 当前环境未处于页面关闭、Worker 终止等导致回调被静默丢弃的状态
正确注册与保持注册器活跃
FinalizationRegistry 实例必须被全局或长期存活的作用域持有，否则它自身也可能被回收，导致监听失效：
// ✅ 正确：注册器保存在模块顶层作用域
const registry = new FinalizationRegistry((heldValue) => {
console.log('对象已被回收，关联值：', heldValue);
});
// ✅ 注册时传入要监听的对象 + 附加数据（可为任意值，但不可是强引用该对象的值）
const obj = { id: 'user-123' };
registry.register(obj, { log: `created at ${Date.now()}` }, obj); // 第三个参数是“unregister token”，通常就是对象本身
// ❌ 错误：registry 是局部变量，可能很快被回收
function setup() {
const badRegistry = new FinalizationRegistry(() => {});
badRegistry.register(obj, 'data');
} // 函数结束后，badRegistry 失去引用，监听失效
无法用于精确计时或资源同步释放
由于回调异步、延迟、且不保证执行，它不适合以下场景：
- 测量 GC 发生的具体毫秒时间（V8 不暴露 GC 时间戳）
- 作为资源清理的唯一手段（如关闭文件句柄、取消网络请求）——应优先使用显式 .close() 或 AbortController
- 依赖回调顺序或频率做业务逻辑（多次 register 同一对象，只保留最后一次 token）
- 调试内存泄漏时当作“对象销毁通知”——它不证明对象一定泄漏，也不证明一定被回收（可能只是还没轮到 GC）
实用定位：轻量级诊断与非关键日志
它真正的价值在于低开销、无侵入的生命周期观察，适合：
- 开发阶段辅助验证对象是否“理论上可被回收”（配合 performance.memory 和 Chrome DevTools 的 heap snapshot 对照）
- 记录某类临时对象的大致存活周期（例如缓存项、事件监听器包装器），用于容量趋势分析
- 在测试中确认某些手动 unregister 操作是否生效（例如调用 registry.unregister(token) 后，对应回调不再触发）
