WeakRef 不能直接管理 WebGL 纹理生命周期，因其仅能弱引用 JS 层 wrapper 对象，无法安全持有或感知 GPU 底层 texture 句柄；真正释放必须显式调用 gl.deleteTexture()，WeakRef 仅辅助探测引用状态，不替代主动资源管理。
WeakRef 本身不能触发 WebGL 资源释放，它只提供“可被 GC 的弱引用”，真正释放必须调用 gl.deleteTexture()；缓存有效性取决于你是否在业务中维持强引用，否则 WeakRef 持有的 texture 会立刻失效。
为什么 WeakRef 不能直接管理 WebGL 纹理生命周期
WebGLTexture 实例不是 JS 可控的普通对象：它背后是 GPU 句柄，JS 引擎无法通过弱引用感知其真实存活状态。WeakRef 只能追踪 JS 层 wrapper 对象（如 { texture, id }），而不能安全包裹 gl.createTexture() 返回的原始 texture 对象——后者在某些浏览器中甚至无法被 WeakRef 正确持有。
常见错误现象：weakRef.deref() 突然返回 undefined，但纹理仍在 GPU 中占用内存；或更糟：业务逻辑误以为资源已释放，重复创建新纹理导致显存翻倍。
- WeakRef 不等于自动释放，它只是“不阻止 GC”的引用方式
- texture 对象本身不可被 WeakRef 安全持有（Chrome 120+ 有部分支持，但 Safari 和旧版 Firefox 会静默失败）
- 必须用一个轻量 wrapper 对象（如
{ texture, createdAt }）作为 WeakRef 的目标，再由 wrapper 关联真实 texture
如何构造一个真正可用的 WeakRef + 显式释放混合管理器
核心思路：WeakRef 仅用于“探测是否还有活跃引用”，所有释放动作仍由明确的业务节点（如组件卸载、场景切换）驱动，WeakRef 回调只作日志或告警。
示例结构：
class TextureCache {
constructor(gl) {
this.gl = gl;
this.cache = new Map(); // key: id → { ref: WeakRef, createdAt: Date }
}
get(id) {
const entry = this.cache.get(id);
if (!entry) return null;
const texture = entry.ref.deref();
return texture ?? null; // 可能已 GC，但 GPU 内存未清
}
set(id, texture) {
// 必须包装，不能直接 new WeakRef(texture)
const wrapper = { texture, id, gl: this.gl };
this.cache.set(id, {
ref: new WeakRef(wrapper),
createdAt: Date.now()
});
}
// ✅ 真正释放入口：业务调用此方法
delete(id) {
const entry = this.cache.get(id);
if (entry && entry.ref.deref()) {
this.gl.deleteTexture(entry.ref.deref().texture);
}
this.cache.delete(id);
}
}
- WeakRef 持有的是
wrapper，不是texture；wrapper 中保留gl引用是为了在delete()时能调用正确上下文 -
get()返回null并不表示 texture 已释放，只表示 JS 层无强引用——GPU 内存可能还在 - 必须暴露
delete()方法供业务主动调用，不能依赖 WeakRef 回调清理
WeakRef 回调里能做什么（以及绝对不能做什么）
WeakRef 不支持注册回调（那是 FinalizationRegistry 的事），所以想“自动触发释放”必须组合使用：WeakRef + FinalizationRegistry。但要注意两者分工：
-
FinalizationRegistry注册时，键必须是 wrapper 对象（同上），不能是 texture - 回调中禁止任何
this.gl.deleteTexture()调用——此时this.gl很可能已丢失或无效 - 回调中只允许：记录
console.warn(`Texture ${id} leaked, never deleted`)、上报监控埋点、触发开发者工具提示 - 如果真要尝试兜底清理，先检查
this.gl.isContextLost?.() === false，但不要依赖它成功
按需缓存的实际生效条件是什么
“按需缓存”效果是否成立，完全取决于你的业务是否维持了对 wrapper 的强引用。一旦 wrapper 被 GC，WeakRef 就失效，缓存即断链——这不是 bug，是 WeakRef 的设计本意。
典型失效场景：
- 在函数作用域内创建 wrapper 并传给 WeakRef，函数退出后 wrapper 立刻被回收
- React 组件中每次渲染都新建 wrapper，但没保存到 state 或 ref 中，导致缓存无法跨渲染周期存在
- 把 wrapper 存在局部变量或未导出的模块变量里，模块被热更新或重载后引用丢失
真正稳定的缓存，需要 wrapper 至少被一个长期存活的对象持有（如全局 TextureCache 实例、React Context 提供的 store、或 class 实例的属性）。WeakRef 只是让这个持有关系“不阻碍 GC”，而不是“替代持有”。
