chrome devtools performance面板中“gpu memory”曲线仅为v8估算值，非真实显存读数，且自chrome 115+起已被弃用；真实显存占用须通过shift+esc打开任务管理器并启用gpu memory列查看，或结合rendering面板的layers、paint flashing和fps meter分析渲染层与纹理生命周期。
Chrome DevTools 没有叫“层面板”的功能，你实际想查的是 GPU 显存（GPU memory）占用，但 DevTools 本身不直接暴露显存数据——它只提供间接线索，且仅限于渲染管线相关的内存指标（如 GPU Memory 在任务管理器中可见，或 Textures、Layers 等在 Rendering 面板中可观察）。真正的显存泄漏排查必须绕开“面板”幻觉，聚焦可验证的渲染行为和资源生命周期。
为什么 Performance 面板里的 “GPU Memory” 不可靠
Performance 面板勾选 Memory 后显示的 GPU Memory 曲线，其实是 V8 引擎对 GPU 资源的粗略估算，并非真实显存读数。它不区分显存/系统内存混合分配（如某些 WebGL 纹理后备存储），也不反映驱动层未释放的缓冲区。更关键的是：该字段在 Chrome 115+ 版本中已被标记为 deprecated，部分新版 DevTools 甚至默认隐藏。
- 它可能长时间为 0，即使页面正大量使用
WebGLRenderingContext或OffscreenCanvas - 曲线突增后不回落，未必是泄漏——可能是纹理上传延迟、驱动内部缓存策略导致
- 无法关联到具体 JS 对象或 DOM 元素，纯数值无上下文
用 Rendering 面板盯住 Layers 和 Paint Profiles
真正影响显存的关键资源会落地为渲染层（Layer）和绘制纹理（Texture）。打开 DevTools → More Tools → Rendering，勾选以下三项：
-
Paint flashing：高频重绘区域会持续高亮，暗示不必要的will-change: transform或强制同步布局 -
Layer borders：每层边框颜色对应合成器类型；过多绿色/蓝色层（尤其是脱离文档流的position: fixed元素）会堆积显存 -
FPS meter：若帧率稳定但GPU使用率长期 >70%，需检查是否创建了超大canvas或未压缩的ImageBitmap
特别注意：通过 document.createElement('canvas') 创建但未插入 DOM 的 canvas，只要调用了 getContext('2d') 或 getContext('webgl')，就可能已分配 GPU 资源——Rendering 面板不会显示它，但它占着显存。
从 Task Manager 找到真实 GPU 内存峰值
这是唯一能确认显存是否失控的入口：按 Shift+Esc 打开 Chrome 任务管理器，添加列 GPU memory（右键表头 → View column → 勾选）。观察目标标签页的该值：
- 普通页面应 若切换路由或关闭模态框后该值不降反升，大概率存在泄漏
- 对比
Memory列（JS 堆）与GPU memory列走势：若前者平稳而后者飙升，问题一定出在渲染层或 WebGL 资源上
此时不要急着看代码——先禁用所有第三方库（如 Three.js、PixiJS），再刷新，看 GPU memory 是否回归基线。如果是，说明泄漏来自库的资源未销毁逻辑，而非你的业务代码。
WebGL 和 OffscreenCanvas 的显存清理陷阱
显存泄漏几乎都源于“创建了资源但没调用销毁方法”。常见错误包括：
- 用
new WebGLRenderingContext（实际是canvas.getContext('webgl')）后，未在组件卸载时调用gl.deleteTexture()、gl.deleteBuffer()等显式释放 - 使用
createImageBitmap()加载图片后，未在不需要时调用imageBitmap.close()（尤其在OffscreenCanvas场景下） - 反复调用
canvas.toDataURL()或canvas.toBlob()生成大量Blob对象，这些对象底层可能绑定 GPU 纹理，且URL.createObjectURL()后忘记URL.revokeObjectURL()
验证方式：在 Console 中执行 chrome.gpu.getMemoryInfo()（需启用实验标志 --enable-features=WebGPU），但该 API 不稳定；更务实的做法是，在疑似泄漏点后手动触发一次页面级强制刷新（非 reload），观察 Task Manager 中 GPU memory 是否归零——不归零，就是资源被 JS 对象强引用着，比如某个全局 textureCache Map 里还存着已废弃的 WebGLTexture。
显存不像 JS 堆那样有 GC 可依赖，它完全依赖开发者显式释放。最易被忽略的是：即使你调用了 gl.deleteTexture()，如果该 texture 还被某个 shader program 绑定着（gl.bindTexture() 后未解绑），驱动仍会保留其内存。清理顺序必须严格：先解绑，再删除。
