finalizationregistry 不能直接释放 webgl 资源，仅作兜底告警；必须主动调用 gl.deletetexture() 等方法显式释放，注册键须为可追踪的 wrapper 对象，回调中禁止访问 webgl 上下文。
FinalizationRegistry 不能直接释放 WebGL 资源
它只能作为“兜底提醒”，不是资源管理的主干逻辑。WebGL 上下文、WebGLTexture、WebGLBuffer 等对象由 GPU 驱动管理，JS 引擎无法强制销毁；FinalizationRegistry 的回调仅在 JS 对象被 GC 后**可能**触发，且时机不可控、不保证执行，甚至在页面卸载前都可能被跳过。
实际开发中必须主动调用 gl.deleteTexture()、gl.deleteBuffer()、gl.deleteProgram() 等原生方法释放——FinalizationRegistry 只能用于日志告警或调试辅助。
注册时必须传入可被追踪的持有者对象
注册进 FinalizationRegistry 的键（第一个参数）必须是 JS 对象（如一个轻量 wrapper），不能是原始值或 WebGL 对象本身（它们不可被弱引用追踪）。常见错误是直接传 texture 或 buffer，这会导致注册失败且无报错。
- ✅ 正确：用一个空对象或带元数据的 wrapper 包裹资源句柄，例如
{ id: 'tex-123', gl: gl, target: gl.TEXTURE_2D } - ❌ 错误：直接传
gl.createTexture()返回的WebGLTexture实例 - ⚠️ 注意：wrapper 对象需在业务逻辑中保持强引用，否则注册后立刻被 GC，回调马上触发——这不是“释放”，只是提前泄露了资源未清理的事实
回调里不能访问已被销毁的 WebGL 上下文
FinalizationRegistry 回调执行时，gl 上下文大概率已丢失（比如页面隐藏、canvas 被移除、或上下文被 loseContext），此时调用 gl.deleteXXX() 会抛出 INVALID_OPERATION 或静默失败。
实操建议：
- 回调中只做副作用安全的操作：记录 console.warn、上报监控埋点、触发开发者工具提示
- 避免任何对
gl的调用，也不依赖this或闭包中捕获的上下文引用 - 如果真要尝试清理，先检查
gl.isContextLost?.() === false，但不要指望它总为 true
真正可靠的释放路径仍是显式生命周期控制
WebGL 资源释放必须绑定到明确的业务节点：组件卸载、场景切换、模型销毁等。推荐模式：
- 用类封装资源，构造时注册
FinalizationRegistry（仅用于报警），析构时调用dispose()显式释放 - 在
dispose()中按顺序调用gl.deleteXXX()，并置空所有引用（帮助 GC） - 结合
requestIdleCallback批量清理大量资源，避免阻塞主线程 - 对长期存活的全局资源（如共享 shader program），用 WeakMap 关联生命周期，避免意外泄漏
FinalizationRegistry 的价值不在“自动释放”，而在暴露那些你忘了调用 dispose() 的地方——它是个诊断工具，不是替代方案。
