HTML弹球打砖块游戏从零开始实现方法

从零开始手写一个弹球打砖块游戏：这些坑你大概率会踩

聊到手绘弹球游戏，第一个关键就是让画布真正“动”起来。很多人兴冲冲写了个canvas标签，结果画了半天愣是没出东西，其实问题出在最基础的地方。

canvas.getContext('2d') 是画布动画的唯一入口。这不是走个形式——不调用它，canvas就是个空壳子。fillRect()、clearRect()、drawImage()，一个都调不动。常见翻车现场是直接写canvas.fillRect()，然后收到TypeError: canvas.fillRect is not a function。明明名字写对了为啥还报错？因为你拿错了对象。

必须搞清楚几件事：先通过 const ctx = canvas.getContext('2d') 拿到上下文，后续所有绘制操作都挂在它身上。DOM还没加载完就去拿canvas元素，那肯定拿不到，所以document.getElementById()执行时机要放对。另外，canvas宽高别用CSS去设，直接用JS赋值 canvas.width 和 canvas.height，否则画出来的图会被硬生生拉伸，比例全乱套。

requestAnimationFrame() 比 setInterval() 更适合弹球运动

很多新手入门时喜欢用 setInterval() 去控制球速，这个方案其实藏了不少雷。页面切到后台再切回来，你会发现球像长了翅膀一样“瞬移”一段距离——setInterval 在不可见状态下被批量触发，累积的位移量让人措手不及。requestAnimationFrame() 则不同，它由浏览器调度，与屏幕刷新率保持同步（通常是60fps），并且页面不可见时自动暂停，不会浪费资源。

实际操作中的几点提醒：主循环必须用 requestAnimationFrame(gameLoop) 递归调用，别想着用 setInterval(gameLoop, 1000/60) 去模拟。运动逻辑要基于时间差（delta time）计算位移，而不是固定步长。举个例子：ball.x += ball.vx * deltaTime / 16（16ms大致对应1帧）。另外，gameLoop 里尽量避免去做耗时的操作，比如DOM查询、大数组遍历，否则帧率说掉就掉。

球与砖块碰撞检测不能只靠 getBoundingClientRect()

有人可能会说：“直接用 getBoundingClientRect() 不就行了？”但问题是，canvas 里的砖块是纯绘制的图形，没有对应的DOM节点。即使你用div去模拟砖块，这个方法也没法处理旋转、缩放，更别说像素级碰撞——比如球从砖块斜角擦过去，它可能判定为没碰到。真正的弹球游戏必须手动实现AABB（轴对齐包围盒）检测。

具体怎么做？每个砖块保存自己的 x、y、width、height，球保存 x、y、radius。判断碰撞时，球心到砖块最近点的距离平方 ≤ 半径平方就是真碰上了。简化版本可以用矩形包围盒做粗筛：ball.x + ball.radius > brick.x && ball.x - ball.radius < brick.x + brick.width。检测到碰撞后，必须及时翻转对应方向的速度——ball.vy = -ball.vy（上下方向）或 ball.vx = -ball.vx（左右方向），否则球会“粘”在砖块上滑来滑去，体验极差。

键盘事件监听要防重复触发和焦点丢失

直接监听keydown然后立刻移动挡板，你会发现按住方向键时挡板只动了一下——因为浏览器默认机制里，keydown只触发一次，长按后是间歇触发。更糟的是，画布不小心失去焦点（比如点了页面其他地方），keydown事件就完全不理你了。

处理方式是：用布尔状态变量来记录按键状态。比如写一个 const keys = { ArrowLeft: false, ArrowRight: false }，在 keydown 里设为 true，keyup 里设为 false。然后在 gameLoop 中根据 keys.ArrowLeft 的状态持续更新挡板位置，而不是在事件回调里直接改坐标。同时，给 canvas 加上 tabindex="0" 属性，并在初始化时调用 canvas.focus()，确保键盘事件能被正确捕获。

砖块阵列的生成、生命值管理、球速随关卡递增、音效触发时机，这些都不是“加几行代码就能跑”的细节。最容易被忽略的一个陷阱是：球在高速下可能会一帧穿透砖块，即所谓的“隧道效应”。这时候AABB检测会失效，必须做扫掠检测或缩小时间步长。这一步没处理好，玩家就会觉得“明明打中了，为什么不算分？”