Canvas 2D 渲染必须用 requestAnimationFrame 而非 setInterval，因其能自动适配刷新率与页面可见性；游戏主循环应递归调用，结合 Δt 物理计算，并采用扫掠检测或点到矩形边距离校验替代朴素 AABB，防止穿模。
Canvas 2D 渲染循环必须用 requestAnimationFrame，别用 setInterval
用 setInterval 控制游戏帧率会导致时间漂移、卡顿明显，尤其在页面切到后台再切回时容易堆叠定时器。浏览器对 requestAnimationFrame 有原生节流和暂停感知，能自动适配屏幕刷新率（60Hz/120Hz）和页面可见性。
实操建议：
- 主循环写成递归调用：
function gameLoop() { update(); render(); requestAnimationFrame(gameLoop); } - 别在
requestAnimationFrame回调里做耗时计算（如遍历全部砖块做碰撞检测前先粗筛） - 记录上一帧时间戳（
performance.now()），用 Δt 做物理位移，避免帧率波动导致球速不一致
球与挡板/砖块的碰撞检测不能只靠矩形包围盒（AABB）
球是圆形，挡板和砖块是矩形，直接用 rect intersects circle 的朴素判断会漏判边缘碰撞，尤其球速快时出现“穿模”——球从砖块缝隙穿过却不触发销毁。
正确做法是实现“移动扫掠检测”或至少做两步校验：
立即学习“前端免费学习笔记（深入）”；
- 先用 AABB 快速排除完全不相交的情况
- 再对可能相交的砖块，计算球心到矩形四条边的最短距离，判断是否 ≤ 球半径
- 挡板碰撞需额外处理：球横向速度反向后，要限制其 y 方向速度不能为 0（否则球会贴着挡板滑行）
示例关键逻辑：const distToEdge = distanceFromPointToRectEdge(ball.x, ball.y, brick.x, brick.y, brick.width, brick.height); if (distToEdge
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
canvas.getContext('2d') 的状态管理容易被忽略
每次 render() 前若没重置绘图状态，旋转、缩放、全局 alpha、线条宽度等会累积污染后续帧。比如挡板加了阴影效果后，所有砖块也跟着带阴影；或者某次画球用了 ctx.globalCompositeOperation = 'lighter'，结果下一帧砖块颜色异常。
安全做法：
- 每帧开头调用
ctx.save()，结尾调用ctx.restore() - 或更轻量：显式重置关键属性，如
ctx.setTransform(1, 0, 0, 1, 0, 0)、ctx.globalAlpha = 1、ctx.shadowBlur = 0 - 避免在循环中反复设置字体、填充色——提前缓存
ctx.fillStyle，只在需要时改
键盘事件监听必须处理按键重复与同时按下
原生 keydown 在长按方向键时会连续触发，但打砖块里挡板移动应是“持续响应”，不是“按键一次动一下”。另外，用户可能同时按左右键，或按住方向键 + 空格发球，这些都要兼容。
推荐方案是维护一个按键状态对象：
- 监听
keydown和keyup，更新keys[65] = true/false（A 键码） - 在
update()中读取该对象判断移动方向：if (keys[37]) paddle.x -= speed; - 空格发球逻辑放在
keyup里，避免按住空格反复触发 - 注意 Firefox 对某些键（如 F5、Ctrl+R）会触发默认行为，需
e.preventDefault()
键码不用硬记，调试时打印 e.code 更直观，比如 'ArrowLeft'、' ' (space)。
最难调的其实是球在高速下与多个砖块的连续碰撞顺序——同一帧内球可能先后撞到两块砖，但按遍历顺序处理会导致第二块没被检测到。这种边界情况得靠分离轴或子步进（sub-stepping）来缓解，不是加个 if 就能解决的。
