Canvas像素流被闭包意外持有会阻断Blink原生堆纹理释放，导致GPU显存持续增长；需通过引用链异常、显存与绘制脱钩、上下文生命周期错位三点识别。
Canvas 原始像素流（如 ImageData、Uint8ClampedArray 或通过 ctx.getImageData() 获取的像素数组）一旦被闭包意外持有，就可能长期驻留在 GPU 显存中——但更关键的是：它会阻断 Blink 原生堆对相关纹理对象的释放，进而引发显存持续增长。这类泄漏**不会触发 V8 堆 GC 报告**，也**不会在 Performance 面板中显示 JS 堆暴涨**，容易被误判为“没泄漏”。识别它，核心是抓三点：引用链异常、显存增长与绘制行为脱钩、以及 WebGL/2D 上下文生命周期错位。
查闭包中是否意外捕获了 ImageData 或像素缓冲区
在 DevTools 的 Memory > Heap Snapshot 中，按构造函数筛选 ImageData 或 Uint8ClampedArray，展开实例 → 查看 “Retained by” 引用链：
- 若发现它被某个长期存活的函数（如事件监听器、定时器回调、React 组件实例、或 Canvas 封装类的私有字段）直接或间接持有，且该函数本不该在绘制结束后还存在，就是高危信号
- 特别注意箭头函数内直接使用
getImageData()结果却未清空引用的写法：const data = ctx.getImageData(0,0,w,h); return () => console.log(data.width); - 检查是否将
data.data（底层 ArrayBuffer）赋值给了全局变量、缓存 Map、或传入了 Web Worker 但未 transfer（导致 ArrayBuffer 被复制而非移交）
观察 GPU 显存增长是否与绘制频率/尺寸不匹配
打开 DevTools > More Tools > Rendering > Paint flashing & FPS meter，再开启 Memory > GPU Memory 面板（需启用 --enable-features=WebGPU 或 Chrome Canary）：
- 执行一次绘制 → 获取一次
getImageData→ 立即丢弃 → 显存应短暂上升后回落 - 若反复调用但显存阶梯式上涨（尤其在停止绘制后仍不下降），说明像素数据关联的 GPU 纹理未被释放
- 对比真机（iOS Safari / 微信 WebView）与桌面 Chrome：微信小程序中
getImageData返回的其实是模拟对象，显存压力常转移到 Blink 原生堆，此时要重点看 Native Heap 分配趋势
验证 Canvas 上下文是否被多处复用却未重置状态
2D Canvas 的 getImageData 会触发隐式纹理上传；若同一 <canvas> 元素被多个模块共享（比如图表库 + 滤镜插件 + 截图工具），极易因状态残留导致像素缓冲滞留：
- 检查是否在调用
getImageData后，未调用ctx.clearRect()或ctx.resetTransform()，且后续又执行了drawImage(canvas, ...)—— 这会让旧像素数据继续绑定到内部纹理 - 确认 canvas 的
width/height属性是否被动态修改过：每次修改都会重建缓冲区，但旧缓冲区若被闭包引用，就成“幽灵显存” - 在小程序中尤其注意：
canvasToTempFilePath内部也会触发像素读取，若同时有 JS 层 getImageData，二者可能竞争同一帧缓冲，造成重复保留
本质上，这不是 Canvas 自己“吃内存”，而是 JS 闭包无意中成了 GPU 资源的守门人。破局点不在清空 JS 变量，而在于切断像素数据与长期作用域的绑定——要么用完立即 data = null，要么用 createImageBitmap 替代原始数组，让系统接管生命周期。
