canvas 游戏随运行时间推移逐渐变慢，通常并非因 dom 查询或音频播放本身导致，而是因在动画循环中重复绑定未清理的事件监听器，造成监听器数量指数级增长，最终拖垮事件处理性能。
canvas 游戏随运行时间推移逐渐变慢，通常并非因 dom 查询或音频播放本身导致，而是因在动画循环中重复绑定未清理的事件监听器，造成监听器数量指数级增长，最终拖垮事件处理性能。
在基于 requestAnimationFrame 或 setInterval 的 Canvas 游戏主循环中，若将 addEventListener 调用写在每帧更新逻辑内（如 update() 函数中），会持续为同一元素、同一事件注册新监听器——而旧监听器并未被移除。例如问题中这段代码：
// ❌ 危险：在动画循环中反复执行
bgm8.addEventListener('ended', function () {
this.currentTime = 0;
this.play();
}, false);每次调用都会新增一个 'ended' 监听器。假设帧率为 60 FPS，运行 2 分钟（120 秒）后，该监听器将被注册 7200 次。当音频自然结束时，浏览器需同步触发全部 7200 个回调函数，引发显著卡顿甚至主线程阻塞。
✅ 正确做法：避免重复绑定
方案一：移出循环，仅绑定一次（推荐）
将事件监听器注册逻辑放在初始化阶段（如资源加载完成、DOM 就绪后），而非每帧执行：
// ✅ 正确：初始化时绑定一次
const bgm8 = document.getElementById('bgm8');
bgm8.addEventListener('ended', () => {
bgm8.currentTime = 0;
bgm8.play().catch(e => console.warn('Auto-play prevented:', e));
});方案二：使用 { once: true }（适用于一次性逻辑）
若确实需要在循环中动态添加（如条件触发音效），且该监听器只需响应一次，明确声明 once: true：
// ✅ 安全：自动清理，无需手动 removeEventListener
audioElement.addEventListener('ended', () => {
audioElement.currentTime = 0;
audioElement.play();
}, { once: true });⚠️ 注意：{ once: true } 不适用于需循环重播的背景音乐——它只触发一次即自动解绑。对 BGM 应采用方案一 + 手动控制播放逻辑。
其他常见性能陷阱（辅助排查）
-
高频 document.getElementById：虽单次开销小，但每帧多次调用仍可累积。建议在初始化时缓存引用：
// 初始化时 const showerDoor1 = document.getElementById('showerDoor1'); const erlik1 = document.getElementById('erlik1'); // 循环中直接使用 setTimeout(() => { showerDoor1.play(); setTimeout(() => erlik1.play(), 1000); }, 1000); 嵌套 setTimeout 链：易导致定时器失控或内存泄漏。优先使用 Promise + async/await 或集中管理定时任务队列。
ES Module 动态导入：import 语句位于模块顶层是静态解析的，不会在运行时重复执行，不是性能瓶颈；但若误用 import() 动态导入并在循环中调用，则需警惕。
总结
Canvas 游戏“越玩越慢”的典型元凶，往往不是渲染或音频本身，而是事件监听器的失控堆积。核心原则是：
? 监听器绑定 ≠ 渲染逻辑：绝不放在 update() 或 render() 中；
? 谁绑定，谁负责清理：若必须动态绑定，务必保存函数引用并配对调用 removeEventListener；
? 善用现代选项：{ once: true }、{ passive: true }（对 touchstart/wheel 等）可显著提升响应效率。
通过精简事件注册路径、缓存 DOM 引用、结构化异步控制，即可让 Canvas 游戏长期稳定运行于 60 FPS。
