Canvas 频繁绘制导致内存泄漏的典型表现是页面卡顿、FPS 下降、JS 堆持续增长且 GC 后不回落，主因是每帧新建 Image/Canvas/路径对象未释放引用，或事件监听器未解绑；应复用离屏 canvas、ImageBitmap 缓存、对象池及前置样式设置，并避免 getImageData、measureText 等高频分配操作。
Canvas 绘制频繁触发内存泄漏的典型表现
页面卡顿、FPS 下降、DevTools 中 Memory 面板显示 JS 堆持续增长，且 GC 后不回落——这往往不是“内存大”，而是对象没被回收。常见于每帧新建 Image、Canvas 或路径对象，又未显式释放引用。
-
new Image()加载后未缓存复用，或加载失败未清理onerror回调引用 - 每帧调用
ctx.createPattern()或ctx.createLinearGradient()但未保存复用 - 使用
ctx.drawImage()绘制离屏canvas时，该离屏 canvas 被反复创建而非复用 - 事件监听器绑定在动态生成的游戏对象上，对象销毁时未调用
removeEventListener()
如何安全复用 canvas 和绘图资源
离屏 canvas 不是“用完就扔”的临时画布，而是应作为可重用的绘制缓冲区。关键在尺寸固定、生命周期可控、不随游戏对象频繁增删。
- 全局只创建 1–2 个固定尺寸的离屏
canvas（如offscreenCanvas），所有精灵预渲染都复用它 - 复用前必须清空：调用
offscreenCtx.clearRect(0, 0, width, height)，而非仅靠width/height重设（后者会重建缓冲区） - 图像资源统一走
ImageBitmap缓存（尤其 WebP/AVIF）：createImageBitmap(img)后存入 Map，避免重复解码 - 字体、阴影等样式设置尽量前置，避免每帧调用
ctx.font = '...'等赋值（V8 会隐式创建新对象）
对象池代替 new/delete 是最有效的回收手段
JavaScript 没有手动内存管理，但高频创建/销毁（如子弹、粒子、敌人）必然拖慢 GC。对象池不是“优化锦上添花”，而是 WebGL/Canvas 小游戏的生存底线。
- 为每个高频类（如
Bullet、Particle）单独建池，用数组 +freeList索引管理，而非单个Map - 对象复用时重置关键字段（
x,y,alive,life），**不要**在reset()里重新分配数组或对象字面量 - 池大小按峰值预估（如最多同时存在 200 发子弹 → 池容量设为 256），避免运行时扩容导致内存抖动
- 禁用
delete或null清理属性——直接覆盖值；GC 不关心“空对象”，只关心“不可达引用”
requestAnimationFrame 中哪些操作真正在吃内存
很多开发者以为“只要没 new 就没事”，但某些看似无害的 API 调用会在底层持续分配纹理或临时 buffer。
立即学习“前端免费学习笔记（深入）”；
-
ctx.getImageData()和ctx.putImageData()每次都分配新Uint8ClampedArray，非必要不用；需像素操作时改用OffscreenCanvas.transferToImageBitmap() -
ctx.measureText()返回新TextMetrics对象，高频文本测量要缓存结果，或改用固定宽度字体 + 查表法 - 使用
ctx.setTransform()代替连续rotate()/scale()，减少矩阵对象临时创建 - 关闭
willReadFrequently: true（仅当真需频繁读像素时启用），否则 Chrome 会强制用 CPU backend，内存占用翻倍
真正难处理的从来不是“怎么释放”，而是“谁还在引用它”。检查 console.memory 和 DevTools 的 Heap Snapshot 对比两次 GC 后的 retained size，重点关注 Closure 和 HTMLImageElement 的 dominator tree 路径——90% 的顽固内存都卡在这里。
