$$('*').length是检测DOM泄漏最轻量指标，执行闭环操作后若节点数持续线性增长（如每次+250～300），即可锁定泄漏；需排除缓存禁用等干扰，并检查闭包、事件监听器及全局引用是否导致Detached节点滞留。
高频 DOM 操作在 HTML 游戏中不会直接“吃满内存”，但会快速推高 JS 堆与 DOM 节点数，触发 GC 频繁、重排开销激增、Detached 节点滞留——最终表现为卡顿、掉帧、甚至页面无响应。关键不是节点数量本身，而是节点生命周期是否可控。
怎么用 $$('*').length 快速判断 DOM 是否泄漏
这是最轻量、最贴近真实渲染压力的指标，比 performance.memory.usedJSHeapSize 更早暴露问题。
- 打开 DevTools Console，执行
$$('*').length记下基线（比如 8421） - 执行一次完整游戏循环：进入关卡 → 触发若干次敌人生成/销毁 → 返回主菜单 → 等待 1.5 秒
- 再跑一次
$$('*').length，若变成 8693，且重复三次后每次 +250～300，基本锁定泄漏 - 注意排除干扰：确保没开调试面板的“Disable cache”或“Emulate network conditions”，这些会阻止资源释放
removeChild() 后节点还在内存里？检查三件事
DOM 节点被移除不等于被回收。浏览器只在它彻底不可达时才 GC，而闭包、事件监听器、全局缓存都可能钉住它。
- 调用
getEventListeners(node)查看是否残留未解绑的click、animationend或自定义事件 - 检查是否有全局 Map/Array 缓存了该节点，例如
window.gameEntities.push(node)但没配对.splice() - 确认没用
node.remove()替代parent.removeChild(node)—— 在 IE11 和旧 Edge 中，remove()不触发事件清理，必须显式removeEventListener
为什么对象池比 new Element() 更适合游戏实体
每秒生成销毁上百个子弹、粒子或 UI 提示框时，document.createElement('div') 的开销不是“慢”，而是“不可控”：内存分配 + 样式树挂载 + layout → paint 全流程，叠加 GC 压力直接拖垮 rAF。
立即学习“前端免费学习笔记（深入）”；
- 复用池必须清空
textContent和innerHTML，否则残留内容会在下次create()后意外显示 - 事件绑定必须在
create()取出后做，解绑必须在recover()前完成；禁止在createFn里预设监听器 - 池大小建议 32–128，过小导致频繁扩容，过大让空闲节点长期驻留，反而干扰 GC
innerHTML 批量插入 vs DocumentFragment：游戏场景选哪个
两者都不是银弹。批量 innerHTML 在首次渲染快，但后续更新需全量替换；DocumentFragment 更可控，但手动 append 多层结构代码更重。
- 静态 UI（如技能栏、血条背景）用
innerHTML一次性写入，避免反复操作 - 动态区域（如敌人列表、弹道轨迹容器）必须用
DocumentFragment+replaceChild，否则每帧innerHTML = ''会触发两次重排（清空 + 重建） - 绝对不要在循环里拼接字符串再赋值
innerHTML——V8 对长字符串拼接有优化，但 DOM 解析仍为单次大开销；改用数组.push()+.join('')更稳
真正卡住游戏的，往往不是“用了多少 DOM”，而是“删没删干净”和“复用有没有断链”。一个没清理的 requestAnimationFrame 回调，比一千个静态 div 更危险。
