张赫尔说到Python游戏开发，碰撞检测是绕不开的一道坎。
开局一张桌子，打怪、拾取、跳跃、卡墙角，全都在背后靠一套碰撞检测逻辑撑住。很多初学者写小游戏时，第一个坎就是"到底怎么判断两个东西撞上了"，自己拍了半天键盘，发现两张图片叠在一起了，代码却毫无反应。今天这篇东西，我就围绕Python游戏里的碰撞检测实现，把从最基础到工程上真正能用的方案，连同我在实际项目里踩过的坑，一次讲透。
这篇内容适合两种人：一是刚开始用Pygame或类似2D框架写小游戏、对碰撞检测只有模糊概念的新手；二是已经有基础、但总觉得自己写的检测逻辑又慢又别扭，想系统了解一下不同方案选型的人。看文字之前你先有个概念，所谓碰撞检测，本质就是个"几何求交"问题——用数学去回答两个物体在空间上有没有重叠。明白这一点，后面所有方法都好懂。
1. 从简单到复杂：碰撞检测的思路拆解
1.1 先想清楚你要什么级别的碰撞精度
写游戏的时候第一件事不是急着写代码，而是想明白这个游戏需要多"真"的碰撞。直接说结论：90%的2D小游戏用最简单的矩形碰撞就够了，剩下的要么是精确到像素的刚需，要么是懒得优化的借口。
我见过太多人一上来就做像素级碰撞，每帧检查每个物体的每个像素透明度，结果帧数被拖到个位数。你要知道，玩家在看到游戏画面那一刻，第一反应是"有没有穿模"，第二反应是"手感顺不顺"，真没几个人会在意角色脑袋旁边的两三个像素是不是和墙缝完美贴合。
所以在动手之前，先列出来你的游戏里有哪些物体、它们在物理上大概长什么样。举个例子：小人是矩形，子弹是圆形，墙体是矩形，金币是圆形。一共有两种形状，大部分情况都能用矩形碰撞去兜住，只有用圆形更合适的地方才单独做圆形碰撞。这就是我在项目里一直用的"优先用简单形状包裹复杂物体"策略。
1.2 常见的两类碰撞检测思路
抛开具体数学公式，碰撞检测大致分成两派：
连续碰撞检测的意思是，物体移动前先计算它会不会在移动过程中穿过某个障碍物，然后提前处理。这种思路在弹球游戏、赛车游戏里比较常见，优点是高速运动的物体不会被"隧道效应"漏掉。
离散碰撞检测则是每帧计算物体当前的位置有没有重叠，这是绝大多数2D框架的常规做法。Pygame里你每一帧更新坐标，然后计算矩形相交，这就是离散检测。
你可能会问，哪种更好？我的经验是：离散检测实现简单、够用，但高速小球一帧穿过薄墙就是它的硬伤；连续检测精确，但计算量和复杂度一下子会上来。这两个概念后面在具体问题里会再碰到，这里先有个印象。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 矩形碰撞：AABB检测的原理与实现
2.1 什么是AABB，为什么它能成为默认方案
AABB的全称是Axis-Aligned Bounding Box，轴对齐包围盒。简单解释就是：每个物体用一个不旋转的矩形框包起来，矩形的边始终和坐标系平行。这是常见碰撞检测方案里最基础也最实用的一种，没有之一。
代码实现它只需要四个值：x、y、width、height。判断两个矩形是否碰撞，逻辑非常直白：
- 两个矩形左右方向上有重叠（甲的右边 >= 乙的左边，而且甲的左边 <= 乙的右边）；
- 同时上下方向上也有重叠（甲的底边 >= 乙的顶边，而且甲的顶边 <= 乙的底边）。
这两个条件同时成立，就是碰撞。用代码写出来：
python复制def rects_collide(rect_a, rect_b):
# rect: (x, y, width, height)
x1, y1, w1, h1 = rect_a
x2, y2, w2, h2 = rect_b
if x1 + w1 >= x2 and x1 <= x2 + w2:
if y1 + h1 >= y2 and y1 <= y2 + h2:
return True
return False
就这么简单。没有平方根，没有角度运算，只有四个比较。如果用的是Pygame，你把rect_a和rect_b换成pygame.Rect对象，直接调用colliderect()，底层就是这套逻辑，效率极高，完全不用自己造轮子。
2.2 边界条件：到底算不算碰上的细节
上面那个代码有个细节值得琢磨：我把等号也放进去了。也就是说当两个矩形边缘刚好贴合的时候，判定为碰撞。这在不同游戏里是有讲究的。
如果你把碰撞定义成"重叠才算"，那边缘刚好贴住就该返回False。可实际开发里，你要考虑物理反馈的连续性。拿平台跳跃游戏举例，角色站在地面上，角色底部和地面顶部是重合了一条缝的。这条缝的像素级状态每帧都可能有浮点误差，如果把"贴住"排除在外，角色可能会落地后瞬间又穿过地面，产生肉眼可见的抖动。
所以我的经验是，做碰撞检测的通用函数时把边缘贴合也算碰撞，然后在具体的碰撞响应逻辑里再去细分是"站在上面"还是"撞在侧面"。这套逻辑后面接位移修正的时候特别好用。
2.3 Pygame的Rect类：不只是个数据结构
Pygame里的pygame.Rect除了能存坐标尺寸，还有一堆内置方法。除了colliderect()，还有：
collidepoint(x, y)：判断某个点是否在矩形内；collidelist(list)：和一个矩形列表逐一检测，返回第一个碰撞的索引；collidedict(dict)：和字典形式的矩形组检测，返回键名；clip()：计算两个矩形的重叠区域，返回一个新的Rect。
我用最频繁的是colliderect()和collidelist()。特别是collidelist，在你需要"这颗子弹有没有撞到任何敌人"这种场景时，一行代码就搞定，而且它内部一旦发现碰撞就立即返回，不用把所有敌人扫完，性能上有天然优势。
在实际项目里，我习惯把Rect统一存成浮点坐标，而不是直接存整数的Rect。原因很简单：游戏物体每帧位移经常是小数（比如速度是1.7像素/帧），如果用整数Rect存坐标，每帧取整会累积误差，物体跑一会儿位置就漂了。正确的做法是自己维护浮点坐标，渲染或者检测的瞬间再转成Rect。
3. 圆形碰撞与像素级碰撞：什么时候需要更精细的检测
3.1 圆形碰撞：距离比较法
矩形AABB的最大问题是对角线位置假阳性率高。比如一个斜45度方向的圆形和一个墙角，矩形包过去之后明明两个物体没挨着，矩形却重叠了。这种场景下圆形碰撞就派上用场。
圆形碰撞的逻辑更直觉：两个圆相撞，当且仅当圆心之间的距离小于等于两个圆半径之和。需要用到的只是勾股定理：
python复制import math
def circles_collide(cx1, cy1, r1, cx2, cy2, r2):
dx = cx1 - cx2
dy = cy1 - cy2
distance_sq = dx * dx + dy * dy
radius_sum = r1 + r2
return distance_sq <= radius_sum * radius_sq
这里有个性能细节：比较的是距离平方和半径平方的平方（其实是半径和的平方），而不是直接开平方。因为开平方计算开销远高于乘法和加法，游戏每帧可能要做几百上千次碰撞检测，能省就省。
经验之谈：如果游戏里一个是圆形一个是矩形，怎么检测？看你图形的复杂度。最简单的是用圆的外接矩形去和矩形做AABB检测，精度不够但速度快；要求高一点的，可以把矩形拆成四条线段，分别算圆心到线段的距离，降到三个值以内就算撞上。这个方案实现起来不算复杂，但我必须承认，除非那一个圆恰好特别大，否则多数2D游戏根本不需要走到这一步。
3.2 像素级检测：精确但奢侈
像素级碰撞检测的逻辑是：两张图片都不透明的地方重叠了，才算碰撞。常见做法是先做AABB粗筛，只有矩形已经重叠了，再进入像素级精确判断；精确判断时把两个矩形的重叠区域找出来，逐像素比较两张图的alpha值。
python复制def pixel_collision(mask_a, mask_b, offset_a, offset_b):
# 用pygame.mask.Mask对象
# mask_a和mask_b是pygame.Mask
return mask_a.overlap(mask_b, (offset_b[0] - offset_a[0], offset_b[1] - offset_a[1]))
Pygame的mask.from_surface()可以从Surface直接生成掩码，overlap()方法返回第一个重叠像素的坐标，拿不到重叠就返回None。这段代码看着爽，但你要清楚它的代价：匹配的是像素级的位运算，两张256x256的图做一次全量检查就是65536次运算，一旦场景里几十个物体都走这条路径，性能直接崩。
所以像素级检测必须是"最后一道保险"，前面一定得有低成本的粗筛。我实际项目中只有一种情况会启用像素检测，就是弹幕游戏里玩家判定点碰撞敌人弹幕的视觉效果太差，换个更小的圆形判定框又不好解释，才不得不上像素检测。真正常用的方案其实是把图像轮廓简化为几个圆的组合，用圆形碰撞去模拟。
4. 工程落地：碰撞响应、运动修正和多物体管理
4.1 不能光检测，还得有"回应"
碰撞检测做到"检测到了"只是完成了一半，剩下的一半是碰撞响应——检测到之后怎么做。最低劣的响应方式是把重叠的物体互相弹开，但怎么弹都是玄学。
如果你做的是平台跳跃，最常见的需求是：角色撞到地面停在上面，撞到墙壁不再侧移。这时候"先位移后检测"和"检测后修正"就非常关键。
我以前写过一套流程，到现在还觉得简洁好用：
- 记录物体当前速度；
- 先把物体位置按速度更新；
- 对所有可能碰撞的障碍物做AABB检测；
- 如果检测到碰撞，根据穿透方向和物体运动方向，把位置按轴反向推回；
- 速度沿该轴置零；
- 更新状态（落地、撞墙）。
python复制def move_with_collision(entity, dx, dy, obstacles):
# 水平移动
entity.rect.x += dx
for obs in obstacles:
if entity.rect.colliderect(obs.rect):
if dx > 0:
entity.rect.right = obs.rect.left
elif dx < 0:
entity.rect.left = obs.rect.right
entity.vx = 0
# 垂直移动
entity.rect.y += dy
for obs in obstacles:
if entity.rect.colliderect(obs.rect):
if dy > 0:
entity.rect.bottom = obs.rect.top
elif dy < 0:
entity.rect.top = obs.rect.bottom
entity.vy = 0
这套逻辑的精髓在于水平和垂直分开处理。如果同时处理，角色斜着撞到墙角时会被整体弹飞，手感极其奇怪。分开后，水平方向只解决x轴上的问题，垂直方向只解决y轴上的问题，角色可以在靠近墙的时候继续下滑，也可以贴墙向上跳，物理反馈边界清晰。
4.2 多物体碰撞的遍历与优化
场景里有主角、几十个敌人、一堆子弹和道具，最朴素的做法是双层循环：每个物体和其他物体都检测一次。这看起来没毛病，但n个物体就是n*(n-1)/2次检测，100个物体就是4950次。每一帧跑4950次AABB，虽然矩形检测很便宜，但加到一起仍然会拖累性能。
工程上最常用的优化是空间网格（Spatial Grid）。把整个游戏世界划分成固定大小的格子，每个格子维护一个物体列表。检测一个物体的时候，只需要检查它所在的格子以及相邻的八个格子里的物体，不用全场景遍历。
python复制class SpatialGrid:
def __init__(self, cell_size):
self.cell_size = cell_size
self.grid = {}
def _key(self, x, y):
return (int(x // self.cell_size), int(y // self.cell_size))
def insert(self, obj):
key = self._key(obj.rect.x, obj.rect.y)
self.grid.setdefault(key, []).append(obj)
def query(self, obj):
x, y = self._key(obj.rect.x, obj.rect.y)
nearby = []
for dx in (-1, 0, 1):
for dy in (-1, 0, 1):
nearby.extend(self.grid.get((x+dx, y+dy), []))
return nearby
注意这个实现里的格子大小是有讲究的。格子太大，一个格子里的物体太多，查询退化为全遍历；格子太小，物体横跨多个格子，又得维护多个引用。常规做法是让格子边长略大于场景里最大的普通物体尺寸，这样大部分物体只存在于一个格子内，且每个格子里平均物体数少。
我自己的经验值：角色尺寸大概32x32，子弹尺寸16x16，格子取64或80。具体哪个好要靠帧时间实测，但64作为一个初始值很少踩坑。
4.3 静态物体和动态物体分开处理
把物体分成静态（Static）和动态（Dynamic）是很多游戏物理引擎的底层设计思路，自己手写碰撞的时候也值得借鉴。静态物体包括墙壁、地面、柱子这类不会动的东西，动态物体就是玩家、敌人、子弹。
在空间网格里，静态物体其实不用每帧重新插入——它压根不动，只在场景初始化的时候插入一次。每帧只需要处理动态物体的碰撞查询，静态物体列表完全不需要参与驱逐和清理。这样省掉大量最无意义的内存写入操作。
同时动态物体之间也不是全都需要互相检测。子弹不需要和子弹碰撞（除非你要做互相抵消），道具不需要和道具碰撞。每一类碰撞关系单独维护一张表，跑到检测阶段直接跳过无关组合，整个流程跑起来非常干净。
5. 常见问题与排查技巧实录
5.1 子弹穿墙：隧道效应的两种解法
我敢说每个做过打砖块游戏的人都被同一件事恶心过：子弹明明前面有墙，一帧过后就莫名其妙跑到墙后面去了。子弹速度太快，一帧移动20像素，但墙的厚度可能只有4像素。离散检测只看起始位置和终止位置，完全没看到墙在中间穿过的事实。
解决方法有两个。第一个思路是分段移动：把一次大位移拆成若干小位移，每段位移都做一次碰撞检测。比如一帧移动20像素，分成4次每次5像素去移动和检测，只要每次位移量不大于最薄障碍物的厚度，就能拦住子弹。
第二个思路是射线检测（Ray Casting），针对"快速移动的子弹"这类物体，不检测它当前在哪，而是检测它从上个位置到当前位置之间扫过的一条线段有没有碰到障碍。在2D网格地图里做射线扫描（Bresenham线段算法），逐格检查有没有实心格子，每检查一次相当于一次极轻量查询，优势很明显。做塔防、弹幕游戏时，我会偏向射线检测，因为子弹方向单一，计算量可控。
5.2 碰撞抖动与穿透深度
还有一种常见问题：物体在碰撞边界处疯狂抖动。多半是因为碰撞检测后位置修正没做利索。典型场景是：角色贴着墙往墙里推，检测到碰撞就原路推回，但下一帧又推进去一点，再被推回，视觉上就变成了高频抖动。
解决方案是给碰撞修正加"消气"机制，也就是物体如果在某方向上连续多帧被推回，干脆把这个方向的输入清零。写起来就是记录一个contacted_frames计数器，当某轴连续碰撞超过两帧，就不再尝试向那个方向加速，直到玩家主动松开再反向输入。
5.3 调试技巧可视化
调试碰撞检测最忌讳的东西是黑盒。玩着玩着发现哪里穿帮了，却不知道自己的判定区域到底在哪。我强烈建议从写碰撞代码第一天就养成一个习惯：把所有的碰撞盒用半透明颜色叠加画出来。
Pygame里很简单：
python复制for obj in all_objects:
pygame.draw.rect(screen, (0, 255, 0, 80), obj.rect, 2)
注意要用一个不更新内容的Surface糊层，或者直接用pygame.draw.rect往主窗口画细线条，只在你调试的时候开。我看到显示出来的绿色矩形永远比自己角色的图片大一圈，就该知道碰撞盒取得太宽了，该收。视觉反馈在碰撞检测里是最直接的判据，省得逐帧打印坐标对数据。
另外还有一个特别实用的排查思路：如果在碰撞边界上出现"时灵时不灵"，先不要怀疑算法，优先查是不是图片和Rect的中心对齐没做好。比如图片向右移动了几个像素但Rect没跟着平移，碰撞盒和视觉效果就对不上了。这种情况下你以为是穿模，实际上是判定区域偏移了。修正的方式是把Rect的中心对齐到物体的逻辑中心，而不是总用左上角。
5.4 性能排查思路
最后说一下性能。碰撞检测拖慢游戏的时候，肉眼可见的表现是物体一多掉帧严重。这时候别急着优化算法，先按顺序排查这几件事：
- 是不是每帧都在新建大量对象？比如每帧都新建Rect、Mask，这些Python对象的分配开销比你想象中大得多。解决办法是统一对象池。
- 是不是调用了特别昂贵的检测方法？比如用了像素级的
overlap，而且是在所有物体之间循环调用。解决办法是加AABB粗筛。 - 是不是场景中静态物体也在每帧反复参与遍历？解决办法是4.3里说的分开处理。
- 是不是渲染和检测混在一起？检测逻辑被嵌入到绘制代码里，导致先画完一层再检测，循环次数翻倍。解决办法是物理和渲染分离。
说实话，游戏里80%的碰撞性能问题都出在"无脑双层循环"和"像素级检测滥用"这两个点上，把这两条落实，剩下的都是小事。
6. 工具选型：Pygame之外的选择和我的建议
讲到这里，你可能想知道在Python生态里，除了Pygame还有没有别的选择。我简单说几类，不搞排行榜，只说适用方向。
如果你想找一个功能更完整、自带刚体物理和多种碰撞形状的框架，可以考虑Pymunk，它是Chipmunk物理引擎的Python封装，提供圆、多边形、线段等碰撞形状，还带关节、摩擦力、弹力，适合做物理仿真感强的游戏。
如果你的游戏以2D地图和相机、瓦片地图（Tiled）为核心，Pygame自带的pygame.sprite加pygame.mask其实已经够用，但地图碰撞体管理可以借用Tiled编辑器的collision layer，会省很多扩展时间。
工程上还有一种思路：核心物理用Python写，但使用类型标注加性能优化（Cython或Nuitka）编译核心热路径。我实践过一条路：把碰撞检测的逻辑提取成纯函数模块，用Nuitka编译成扩展，整体提速接近一倍，但开发和调试复杂度也明显上升。小游戏达不到性能瓶颈时，建议先把逻辑写对，性能问题交给后续优化。
表格对比常用的几种方案：
| 方案 | 精度 | 性能开销 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| AABB矩形检测 | 低 | 极低 | 很低 | 绝大多数2D游戏 |
| 圆形碰撞 | 低到中 | 低 | 低 | 弹幕、轻量物理 |
| 像素级检测 | 高 | 高 | 中 | 需要精确贴合边界 |
| 空间网格+矩形 | 低 | 中 | 中 | 大场景多物体 |
| Pymunk物理引擎 | 高（含物理模拟） | 中 | 中到高 | 物理仿真类游戏 |
说实话，我看到很多初学者抱着像素级碰撞不放，好像越精细越高级。可实际游戏开发里，判断一个碰撞方案好不好，标准从来不是"数学上有多精确"，而是"玩家觉得手感对不对，性能撑不撑得住"。我在项目里用的默认组合就是空间网格做粗筛，AABB做最终判断，个别眼睛看得见的位置才加圆形修正。这套组合下来，处理几百个物体同时碰撞没出过性能问题。
踩过几次坑之后，我自己整理出几条铁律，分享给你：
- 碰撞检测永远不用全部物体两两检测，先用空间网格或者碰撞层做预筛；
- 像素级检测只在确有需要时做最后一层；
- Rect和图片的锚点必须一致，否则出了问题你根本找不到原因；
- 碰撞修正要分轴进行，永远不要在xy上同时回退；
- 调试时把碰撞盒可视化，别靠猜。
这个内容后续还可以这样扩展：如果你已经在用AABB和空间网格，下一步可以试着给游戏引入简单的分数坐标物理（把移动量拆成整数和小数，避免浮点累加误差），或者给平台格斗类游戏加上更丰富的碰撞响应分轴逻辑。每加一个机制，都会逼着你把碰撞检测模块化得更干净，这中间的代码组织经验，比碰撞算法本身还值钱。