玩游戏的时候，你有没有注意过角色跳上平台刚好不穿模，或者子弹打中敌人瞬间爆炸？这些细节背后，靠的都是碰撞检测。它不像画面那么显眼，但一旦出问题，玩家立马就能感觉到‘不对劲’。
碰撞检测是做什么的
简单说，就是判断两个或多个物体有没有‘碰到’。比如赛车游戏里撞墙停下，格斗游戏里拳脚命中对手，甚至塔防游戏里小怪走到路线终点——这些逻辑都依赖碰撞系统来触发。
很多人以为碰撞就是像素对碰，其实现代游戏用的是数学模型。常见的有 AABB（轴对齐包围盒）、圆形碰撞、多边形碰撞等。AABB 最常用，因为它计算快，适合大多数方形角色和障碍物。
一个简单的 AABB 检测例子
假设我们有两个矩形角色，只需要比较它们的边界坐标：
function checkCollision(rect1, rect2) {
return rect1.x < rect2.x + rect2.width &&
rect1.x + rect1.width > rect2.x &&
rect1.y < rect2.y + rect2.height &&
rect1.y + rect1.height > rect2.y;
}这段代码在 2D 平台游戏里很实用。比如主角跳起来刚好擦过敌人头顶，就不会触发受伤逻辑，体验就更顺滑。
实际开发中的坑
别看代码短，真做项目时问题一堆。最常见的是‘穿墙’——当角色移动速度太快，一帧就穿过了墙壁的范围，检测失效。这时候就得用‘扫掠检测’或分段检测，把这一帧的路径拆成几段逐步判断。
另一个问题是性能。如果场景里有上百个敌人和子弹，每两个都比一遍，计算量直接爆炸。解决方案是空间分区，比如四叉树或网格桶，只检查附近对象，大幅减少无效对比。
引擎已经做好了，还要自己写吗
Unity、Cocos Creator 这些主流引擎自带物理系统，确实能直接用。但在一些轻量项目或 H5 小游戏中，为了省资源、控精度，开发者还是会手写简化版碰撞逻辑。比如做一个微信小游戏，包体积卡得紧，自己写个 AABB 检测反而更高效。
而且懂原理才能调得准。有时候发现角色明明没碰到却判定失败，翻源码一看是浮点误差积累导致的，这时候知道底层怎么算的，改起来才不抓瞎。
从生活里学设计思路
想想电梯门，人站在门口不动，门也不会关上。这和游戏里的触发区域很像——不是所有碰撞都叫‘碰撞’，有的只是用来激活事件。比如玩家走进某个范围弹提示，这种可以用圆形区域做简单距离判断，连包围盒都不用。
再比如打乒乓球，球拍和球接触时间极短，但必须精准捕捉。对应到游戏里就是‘帧率依赖问题’。60帧下可能没问题，低帧率设备上就会漏判。解决办法是记录移动轨迹，而不是只看起点终点。
碰撞检测看着小，其实藏着不少巧劲。做得好，玩家根本意识不到它的存在；做得差，再漂亮的画面也救不回来。