weakref 和 finalizationregistry 不控制对象生命周期，仅在对象被 gc 回收后提供弱感知与清理入口；真正决定生命周期的是强引用是否存在。
weakref 和 finalizationregistry 不是生命周期控制器，它们不主动管理、也不干预对象的存续时间。它们只在对象**已脱离所有强引用且被 gc 实际回收后**，提供一次弱感知与清理入口。真正决定生命周期的，永远是你自己是否还持有强引用。
WeakRef 的真实作用：让引用“不挡路”
WeakRef 本身不释放内存，也不触发任何操作。它只是把一个强引用“降级”为不计数的引用——垃圾回收器看到 WeakRef，会直接忽略它。
- 必须配合
deref()使用，且每次调用都要检查返回值是否为undefined - 不能用于原始值（string/number/boolean/symbol）、函数、或不可弱引用类型（如 Promise）
- WeakRef 实例自身是普通对象，如果你把它长期存进
Map或数组却不清理，它自己就会占内存 - 常见误用：用
new WeakRef(obj)包一层就以为“安全了”，却还在别处保留着obj的强引用（比如闭包捕获、事件监听器、定时器回调里），此时对象根本不会被回收
FinalizationRegistry 的关键限制：只通知“已终结”，不参与“终结过程”
注册后回调触发，需同时满足三个条件：对象无任何强引用 + GC 已执行并释放该对象 + 引擎调度了 finalizer 队列。这三个环节都不可控、不可预测。
- 回调中拿不到原对象，只能拿到注册时传入的
holdings（推荐用 string、symbol 或轻量 object，如{ type: 'canvas', id: 42 }） - 浏览器中无法主动触发 GC；Node.js 需加
--expose-gc并调用global.gc()，但仍不保证回调立即执行 - DevTools 的“垃圾箱”图标点击仅用于调试，不能用于自动化流程
- 若注册后仍持有目标对象的强引用（哪怕只存在一个未清空的数组里），回调永远不会触发
构建可维护的资源池：必须拆开“存”和“删”
缓存类场景下，WeakRef 负责让值可回收，FinalizationRegistry 负责在回收后删除缓存键。二者必须协同，且顺序不能错。
- 每次
set(key, obj)时，同步做三件事：new WeakRef(obj)、cache.set(key, ref)、registry.register(obj, key, ref) - 其中
ref是unregisterToken，用于将来精准注销注册，避免重复清理或漏清理 -
get(key)必须先取weakRef.deref()，为空则立刻cache.delete(key) - 不要复用同一个 registry 处理不同语义的资源（如 canvas 和 ArrayBuffer），应按资源类型分 registry，便于定位问题
真正可控的生命周期管理：靠切断，不靠监听
想让对象尽快释放，唯一可靠方式是提前移除所有强引用点。WeakRef 和 FinalizationRegistry 只能辅助验证或兜底，不能替代主动设计。
- 避免闭包直接捕获大型对象，改用 ID 或 key，在需要时重新查表或 fetch
- 手动清理异步依赖：清除
setTimeout/setInterval、取消fetch的AbortSignal、移除addEventListener（注意匿名函数无法 remove） - 对 Canvas、WebGL、AudioContext 等，显式调用
ctx.destroy()、gl.deleteTexture()、audioCtx.close() - 注册
registry.register(obj, holdings)后，务必确认代码中再无任何地方持有obj的强引用
