weakref 和 finalizationregistry 无法精准监听大型对象回收——gc 时机不可控、回调不及时、强引用链会完全屏蔽其作用，仅能辅助验证或兜底，不可替代主动断开引用。
WeakRef 和 FinalizationRegistry 无法实现“精准”监听大型对象的回收时机——GC 触发时间不可控、回调不保证立即执行、且闭包/强引用链会完全屏蔽它们的作用。 想靠这两个 API “精准捕获某个大对象何时被释放”，本质上是误用了它们的设计定位。
WeakRef.deref() 返回 undefined 并不表示对象刚被回收
WeakRef 只是不阻止回收，但 deref() 的返回值只反映“此刻是否还能取到对象”，不是 GC 日志。常见误解是轮询 deref() 来“监听”回收，这既低效又不可靠：
- 对象可能还存活，但 GC 尚未运行，
deref()仍返回有效值 - 对象已被回收，但
deref()在下一次 GC 前就调用，返回undefined—— 你并不知道它何时发生的 - 若对象被其他强引用持有（比如还在 DOM 树里、被定时器闭包捕获），
deref()一直有效，但你误以为“它还没被回收”
FinalizationRegistry 回调触发条件极难满足
注册后回调被调用，必须同时满足：对象无任何强引用 + GC 已实际执行并清理该对象 + 引擎完成 finalizer 队列调度。在实际业务中：
- 大型对象（如
ArrayBuffer、ImageBitmap、深层嵌套 JSON）常被隐式强引用：事件监听器、Promise 链、setTimeout回调、console.log缓存、甚至 DevTools 的作用域面板都会延长其生命周期 - Node.js 中需显式启用
--expose-gc，且global.gc()不保证触发所有 finalizer；浏览器中无法主动触发 GC，只能等待（或手动点 DevTools 的垃圾图标，但不可用于自动化） - 回调中拿不到原对象，仅能拿到注册时传入的
holdings（必须是简单值），无法做深度状态判断
真正可控的“精准回收”只能靠主动切断引用链
想让大型对象尽快释放，唯一可靠路径是提前移除所有强引用点。WeakRef/FinalizationRegistry 只能辅助验证或兜底，不能替代主动管理：
- 避免闭包直接捕获大型对象：改用 ID 或 key，在需要时重新 fetch 或查表
- 手动清理异步依赖：清除
setTimeout/setInterval、取消fetchAbortSignal、移除addEventListener（尤其注意匿名函数无法remove） - 对
Canvas、WebGL、AudioContext等资源，显式调用ctx.destroy()、gl.deleteTexture()等，而非等 GC - 用
FinalizationRegistry注册时，holdings推荐传入可追踪的标识（如{ type: 'large-buffer', id: 123 }），并在回调中打日志或上报，仅用于事后分析泄漏点
最易被忽略的一点：你在 registry.register(obj, holdings) 之后，如果还持有 obj 的强引用（哪怕只是把它塞进一个没清空的数组里），这个对象就永远不会被回收，finalizer 也永远不会触发——WeakRef 和 FinalizationRegistry 都不会警告你这一点。
