canvas 游戏运行几分钟后变慢，通常并非内存泄漏或 dom 查询本身所致，而是因在动画循环中重复添加未清理的事件监听器，导致事件处理队列指数级膨胀，引发严重性能退化。
canvas 游戏运行几分钟后变慢，通常并非内存泄漏或 dom 查询本身所致，而是因在动画循环中重复添加未清理的事件监听器，导致事件处理队列指数级膨胀，引发严重性能退化。
在基于 requestAnimationFrame 或 setInterval 的 Canvas 游戏主循环中，若将 addEventListener 调用置于更新逻辑（如 update() 函数）内部，每次循环都会为同一元素、同一事件注册一个全新监听器——而旧监听器并未被移除。随着游戏持续运行（例如 60 FPS 下每分钟 3600 帧），监听器数量线性增长，浏览器需在每次触发事件（如 ended、click）时遍历并调用全部已注册回调，最终造成显著延迟甚至卡顿。
? 典型问题代码（危险模式）
以下代码出现在每帧执行的动画更新逻辑中：
// ❌ 危险：每帧都新增监听器，旧监听器持续累积
bgm8.addEventListener('ended', function () {
this.currentTime = 0;
this.play();
}, false);即使音频对象 bgm8 是单例，该监听器也会在每一帧被重复绑定——10 秒后即新增 600+ 个相同逻辑的监听器，但仅有一个生效，其余全成冗余负担。
✅ 正确实践：一次注册，精准控制
方案一：移出循环，全局初始化（推荐）
将事件监听器注册移至游戏初始化阶段（如 init() 或构造函数中），确保仅执行一次：
// ✅ 正确：初始化时绑定，生命周期内仅一次
function initAudio() {
bgm8.addEventListener('ended', onBgmEnded);
}
function onBgmEnded() {
this.currentTime = 0;
this.play();
}
// 启动游戏时调用
initAudio();方案二：使用 { once: true }（适用于一次性逻辑）
若监听器本就只需响应一次（如音频循环重播），可直接启用原生 once 选项，无需手动管理移除：
// ✅ 简洁安全：浏览器自动清理，无需引用函数
bgm8.addEventListener('ended', () => {
bgm8.currentTime = 0;
bgm8.play();
}, { once: true });⚠️ 注意：{ once: true } 适用于「触发后即失效」场景；若需持续循环（如背景音乐无缝续播），必须采用方案一 + 手动重绑（见下文进阶技巧）。
方案三：动态重绑（高级循环控制）
对于需长期循环播放且依赖状态的音频，可在回调中主动重新绑定：
function setupBgmLoop() {
bgm8.addEventListener('ended', handleBgmEnd, { once: true });
}
function handleBgmEnd() {
bgm8.currentTime = 0;
bgm8.play().catch(e => console.warn('Audio play failed:', e));
setupBgmLoop(); // 重新注册下一次监听
}
setupBgmLoop(); // 初始绑定⚠️ 其他常见误区排查（辅助验证）
- setTimeout/setInterval 泄漏：检查是否在循环中反复创建未清除的定时器（尤其嵌套 setTimeout）。应优先使用 requestAnimationFrame，或对 setInterval 保存 ID 并在退出时 clearInterval(id)。
-
高频 document.getElementById：虽非主因，但频繁 DOM 查询仍影响性能。建议启动时缓存引用：
const showerDoor1 = document.getElementById("showerDoor1"); const erlik1 = document.getElementById("erlik1"); // 后续直接使用 showerDoor1.play() - ES 模块导入：import 语句在模块解析阶段执行，与运行时性能无关，可排除。
? 总结
Canvas 游戏“越玩越慢”的核心陷阱往往藏在看似无害的事件绑定逻辑中。切勿在渲染循环中重复添加监听器——这是最隐蔽也最典型的性能杀手。遵循“初始化注册”或“once: true”原则，配合定时器与 DOM 查询的合理优化，即可彻底解决渐进式卡顿问题。性能优化的第一步，永远是审查事件监听器的生命周期管理。
