Pygame底层机制详解：从Surface到主循环的工程实践

简介：一套面向Python初学者的Pygame入门教程PDF，采用“知识点+示例”的编写方式，系统讲解2D游戏开发的完整路径。内容覆盖游戏主循环、Surface对象、Event事件、Rect区域等核心机制，并深入展开图像、声音、输入输出、绘制函数与字体文本等模块的实际用法，适合想要动手实现飞机大战、贪吃蛇、扫雷等小游戏的学习者。整个资源包共包含1个PDF文件，压缩后仅1.32MB，轻量易用，便于随时下载阅读；目前已有1562人浏览学习，内容源自Pygame系列教程的结构化整理，目录清晰，从环境安装配置到精灵碰撞检测均有分章讲解。读者配合示例逐步操作，可快速完成第一个Pygame程序，并掌握事件监听、FPS控制、屏幕绘图、文本渲染等关键技能，为后续独立开发2D游戏打下扎实基础。

1. 为什么"慢语言"写出的 Pygame 能火二十多年

Python 是解释型语言，按常理它与"游戏"二字沾不上边——可 Pygame 偏偏在 2D 游戏开发与教学领域火了二十多年。想要一套能快速出效果的 Python 游戏课程资源，几乎绕不开它。拆开 Pygame 你会发现，它自己几乎不干重活：底层是 C 语言写的 SDL 负责像素搬运、音频输出与事件采集，Pygame 只负责把 SDL 的功能翻译成几百个 Python 方法。于是你的游戏逻辑跑在解释器里，但真正吃性能的 blit 全在 C 层完成。搞懂 Pygame 的底层机制，就是搞懂"慢语言如何借力编译型底层"，这一层想明白，游戏开发里的卡顿、事件丢失、图像撕裂等问题，你都能直接定位到根因，而不是靠玄学调参数。

2. Surface 与 display：主窗口背后是一块像素矩阵

2.1 Surface 不是画布，是内存里的像素二维数组

人们爱把 Surface 比喻成"白纸"，这个比喻形象，但也容易误导。白纸是物体，Surface 是数据：它本质是一块连续内存，按"每像素多少字节"排布成矩形。比如一个 400×400、32 位色的 Surface，内存里大约有 400×400×4 字节的数据，每个像素四个字节分别存 R、G、B、A 通道。当你调用 fill() 时，Pygame 做的事情就是把这块内存的每个像素字节写成同一个颜色值；调用 get_at() 时，则是从对应偏移量读出颜色。把 Surface 理解成"像素矩阵"，比"白纸"精确得多——尤其是遇到透明、格式转换、性能问题的时候。

创建 Surface 有两个参数常常被人忽略：flags 和 depth。flags 里的 HWSURFACE 尝试把这块内存放到显存，SRCALPHA 则要求每个像素都携带 alpha 通道；depth 指定每个像素用多少位表示颜色，不传时 Pygame 自动匹配当前显示模式。常见的坑是：想要半透明效果却没加 SRCALPHA，fill 时传了带 alpha 的颜色也无效，因为像素格式里根本没有存放 alpha 的位置。

import pygame import sys pygame.init() screen = pygame.display.set_mode((400, 400)) # 关键：加上 SRCALPHA，这个 Surface 的像素才真正有 alpha 通道 face = pygame.Surface((50, 50), flags=pygame.SRCALPHA) face.fill((255, 0, 0, 128)) # 半透明红色，A=128 while True: for event in pygame.event.get(): if event.type == pygame.QUIT: pygame.quit() sys.exit() screen.blit(face, (100, 100)) pygame.display.flip()

这里 (255, 0, 0, 128) 的最后一位不是装饰：128 在 0~255 区间里正好是 50% 透明。blit 到主窗口时，底层会根据源像素的 alpha 与目标像素做 alpha 混合，而不是直接覆盖。如果去掉 SRCALPHA 再试，face.fill 会直接忽略第四个分量——这就是许多人"明明写了透明色却完全不透明"的根因。alpha 混合属于 SDL 在 C 层完成的逐像素操作，Python 只负责发起一次调用，这也正是 Pygame 敢在解释型语言里做游戏图形的原因。

再看一个更深入的点：Surface 还能通过 subsurface() 派生子区域。子 Surface 与父 Surface 共享同一块内存，只是矩形范围不同。这意味着你修改子 Surface 的像素，父 Surface 的对应区域也会变。这个特性在实现滚动地图、局部动画时非常有用，但代价是要小心"我明明只改了一个小块，整张图却变了"的困惑——因为它们在底层本来就是同一块数据。

2.2 set_mode 与双缓冲：为什么画面不会撕裂

pygame.display.set_mode((400, 400)) 做的事情比"建个窗口"多得多。它向系统申请了一个游戏窗口，同时向 SDL 索要一个与窗口关联的 Surface——也就是 screen。screen 和手动创建的 Surface 本质相同，都是像素矩阵，区别在于它背后连着窗口系统的显示通道。

flags 参数里最值得理解的是 DOUBLEBUF。没有双缓冲时，程序是边绘制边显示的，绘制过程中屏幕可能先露出半张图，再补上另外半张，这就是画面撕裂。开启双缓冲后，所有绘制先写到后备缓冲，等一帧内容全部就绪，再一次性交换到屏幕。pygame.display.flip() 这个名字就来自双缓冲的"翻页"操作——把后备缓冲和正在显示的缓冲互换，用户永远看不到画到一半的画面。

与 flip 对应的是 display.update()。update() 不传参数时更新整个窗口，效果等同 flip；传入矩形区域列表时则只刷新指定区域。在方块消除、推箱子这类"大部分画面不变"的游戏里，用 update 做局部刷新能省掉大量无意义的像素搬运，是提升帧率的有效手段。

display 模块还有几个容易被忽略但实际有用的方法：get_surface() 可以取回当前正在显示的 Surface 对象，适合在切换场景后重新获取 screen；set_icon() 设置窗口左上角图标，要求 32×32 尺寸；get_active() 返回窗口是否可见，窗口被最小化时返回 False，可以用来暂停游戏循环里的重计算。

2.3 blit 的本质：一次 C 层的位块传输

如果把 Surface 看成像素矩阵，blit 就是把一块矩阵的像素拷贝到另一块矩阵的指定位置。这个操作在图形学里叫 Bit Block Transfer（位块传输），SDL 原生支持，Pygame 只是包装成 screen.blit(source, dest, area=None, special_flags=0)。source 是要拷贝的 Surface，dest 是目标位置，area 是从 source 上"抠"一个子矩形去拷贝，不传则拷贝整张。

# 从精灵表左上角抠出 32x32 的角色帧，贴到屏幕 (200, 200) 处 screen.blit(sprite_sheet, (200, 200), area=(0, 0, 32, 32))

这段代码常见于精灵图（sprite sheet）的裁剪：一张大图里排满角色的所有动作帧，用 area 参数把当前需要的帧抠出来。如果再加 special_flags 参数，比如 BLEND_RGBA_ADD，blit 就不是简单覆盖了，而是把源像素与目标像素做加法混合，常用于发光、受击闪白等特效。

效率上，blit 的像素循环完全在 C 层，Python 只做一次方法调用。但如果源 Surface 与屏幕像素格式不一致，SDL 拷贝前要逐像素做格式转换，转换成本远高于拷贝本身。这解释了为什么 pygame.image.load("xxx.png").convert() 是教程里的标准写法：convert() 预先把图片像素格式转换成与当前屏幕一致，此后每次 blit 都是同格式拷贝，省掉每帧的隐式转换。带透明通道的图片则用 convert_alpha()，它会额外保留 alpha 信息。

提示：convert() 只对不带透明通道的图片有效；需要透明效果的 PNG 请用 convert_alpha()，否则透明区域可能变成纯黑。

把这几个概念串起来看，一帧画面的产生路径是：set_mode 创建屏幕 Surface → 各精灵 Surface 在初始化时加载并 convert → 主循环里按坐标逐个 blit 到 screen → flip 把 screen 整块交给显卡。这里 screen 是所有绘制的目的地，其他 Surface 都是源。甚至 font.render() 返回的文本对象，本质上也是一个 Surface——文字、图像、绘图在 Pygame 里最终都统一成"由像素矩阵构成的对象"，再通过 blit 搬到主窗口。只要这条管线在心里，什么 fill 白屏、blit 位置不对、转换太慢这类问题，都能按管线逐段排查。

3. 事件与主循环：消息队列如何撑起人机交互

3.1 Event 不是回调，是排队消息

接触过前端的人第一次写 Pygame 都会困惑：为什么没有 button.click 之类的回调？原因在于 Pygame 沿用了 SDL 的事件模型——操作系统产生输入，SDL 把它们包装成结构体放入消息队列，Pygame 的 event 模块围绕队列工作。队列意味着先到先处理，也意味着程序必须主动去取，而不是被动等通知。

取事件有三个常用方法。pygame.event.get() 一次性取出队列里当前所有事件，返回列表，最常用，因为游戏循环希望"这一帧把待处理事件全部消化完"。pygame.event.poll() 只取队首一个，适合单事件循环。pygame.event.wait() 是阻塞式的，队列为空时一直等，适合菜单等待这类场景。

事件队列的设计有个隐藏影响：事件是"消费"型数据。同一帧里调用两次 get()，第二次拿到的是空列表，因为第一次已经把队列取空了。这在多模块架构里是个隐患——如果输入处理逻辑被拆到两个函数里，每个函数都调 get()，事件就会被第一个函数独吞。正确的做法是统一在游戏循环里取一次事件，再分发到各处理函数。

3.2 为什么 get() 必须放在 while True 里

注意 get() 每次调用都会把事件队列清空。如果把 get() 写在循环外，程序只处理启动瞬间的事件，之后玩家的任何操作都无人消费，事件在队列里越积越多，表现为"点了一下没反应，突然全部触发"。这就是游戏主循环存在的第一个理由：持续消费事件。

running = True while running: # 每帧清一次事件队列，处理本帧发生的所有交互 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.KEYDOWN and event.key == pygame.K_ESCAPE: running = False

注意 QUIT 挂在 event.type 上，按键值挂在 event.key 上。QUIT 代表窗口关闭请求，由窗口管理器发出；键盘按下则属于 KEYDOWN。把 QUIT 和 K_ESCAPE 写进同一个 if 是新手常犯的错误——类型和按键是两个维度，必须分两层判断。事件对象是一组属性的集合，不同事件类型携带不同的数据段：鼠标事件带 pos 和 button，键盘事件带 key 和 mod，QUIT 则几乎不携带额外信息。用 dir(event) 或者打印 event.dict可以随时查看到底有哪些字段。

3.3 主循环的三项任务：事件、更新、绘制

游戏主循环常常被说得很玄，剥开只有三件事：处理事件、更新游戏状态、把状态画出来。顺序也重要：先处理输入决定"玩家想做什么"，再更新位置、血量、分数等状态，最后绘制到屏幕。绘制放在更新前面，玩家会看到上一帧的位置；事件处理放最后，输入会延迟一整帧。

import pygame import sys pygame.init() screen = pygame.display.set_mode((400, 300)) clock = pygame.time.Clock() player_x = 200 speed = 5 running = True while running: # 1. 事件阶段：处理所有输入 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.MOUSEBUTTONDOWN and event.button == 1: # 鼠标左键点击：直接跳转到点击位置（事件带坐标信息） player_x = event.pos[0] # 2. 更新阶段：键盘状态驱动持续移动 keys = pygame.key.get_pressed() if keys[pygame.K_LEFT]: player_x -= speed if keys[pygame.K_RIGHT]: player_x += speed # 3. 绘制阶段：清屏、画角色、提交缓冲 screen.fill((0, 0, 0)) pygame.draw.circle(screen, (255, 255, 255), (player_x, 150), 20) pygame.display.flip() clock.tick(60)

这段代码里同时出现了两种输入读取方式。pygame.key.get_pressed() 返回当前所有按键的布尔状态，适合"按住持续移动"；MOUSEBUTTONDOWN 事件只在按下的瞬间触发一次，event.pos 携带点击坐标，适合"点击跳转"。把两者混用会得到意想不到的行为：用 get_pressed() 判断跳跃，按住键时角色每帧都在跳；用 KEYDOWN 判断移动，按键重复功能会导致移动一顿一顿。理解"状态查询"与"事件消息"是两条独立数据通路，是读懂 Pygame 输入体系的关键。

更新阶段承载的是真正的游戏逻辑：角色坐标、子弹轨迹、血量判定、胜负状态。这个阶段不该出现任何 blit 或 flip，否则就破坏了"逻辑与渲染分离"的结构。一个小技巧是，把更新阶段单独抽成 update(dt) 函数，绘制阶段抽成 draw(screen) 函数，主循环只负责调度。这样当你需要暂停游戏时，只需要跳过 update，draw 照常执行——菜单覆盖、暂停画面都能轻松实现。

3.4 QUIT 与 quit()：退出流程别偷懒

标准退出流程是：收到 QUIT 事件 → pygame.quit() → sys.exit()。pygame.quit() 卸载所有 Pygame 模块、释放 SDL 占用的底层资源；sys.exit() 终止 Python 进程。只 quit 不 exit，程序还会继续跑；只 exit 不 quit，部分平台会因资源未释放出现异常。

更稳的写法是把 running 置 False，跳出主循环后再统一清理，而不是在循环体里直接 sys.exit()。这样主循环之后的清理代码才能执行。比如你想在退出前保存游戏进度，直接 exit 会让保存逻辑永远走不到。养成"事件只改标志位，循环结束再退出"的习惯，几乎能避免所有退出相关的诡异 bug。

另外值得了解的是 pygame.event.post() 和 pygame.event.Event()。你可以手动构造一个事件塞进队列，比如"三秒后触发一个敌人出场事件"，或者用自定义事件类型做 UI 按钮回调。自定义事件用 event.custom_type() 生成一个不冲突的事件 ID，配合 set_timer 或者 post，就能把游戏逻辑里的"提醒"也统一到事件模型里处理。

4. 时间、Rect 与 Transform：让画面动起来的底层工具

4.1 Clock.tick()：帧率不是越快越好

游戏画面是一帧帧刷新的，FPS 就是每秒刷新次数。人眼能接受的最低帧率约 30Hz，流畅需要 60Hz 以上。Pygame 控制帧率的标准工具是 pygame.time.Clock()，核心方法是 tick(fps)。

clock = pygame.time.Clock() running = True while running: # tick(60) 返回上一帧耗时(ms)，并睡眠让帧率贴近 60 dt = clock.tick(60) # 用 dt 做时间步修正：帧率低时每次位移变大，保证每秒位移一致 player_x += 200 * dt / 1000

tick(60) 做两件事：记录上一帧消耗的时间，并让程序主动睡眠，使每秒最多跑 60 帧。这里有个新手最常见的坑：用固定速度移动「player_x += 5」，帧率越低，角色每秒位移越小。换台低配电脑，游戏直接变慢；用 dt 做时间步修正后，无论 30 帧还是 60 帧，每秒位移量都一致。这是"帧率无关移动"的标准解法，也是很多老代码"换电脑就变样"的根因。

Clock 对象还有 get_fps() 方法，返回最近一秒实测的帧率平均值。调试时把它打印在窗口标题上，能立刻看到 tick 参数是否生效，也能直观感受优化前后帧率的变化。用 pygame.display.set_caption(f"FPS: {clock.get_fps():.1f}") 就可以在标题栏实时监控。

4.2 get_ticks 与 set_timer：时间的两种用法

pygame.time.get_ticks() 返回从 pygame.init() 到当前时刻的毫秒数，单调递增，适合做冷却计时、动画间隔判断。比如"每 500 毫秒发射一颗子弹"，记录上次发射时间，当前时间减它大于 500 就允许再发射。pygame.time.wait() 则是整程序阻塞指定毫秒，适合开局画面、关卡转场，绝不能放主循环里，否则事件响应会全部冻结。

set_timer(event, millis) 思路不同：让 Pygame 每隔指定毫秒往事件队列塞一个自定义事件。这样"计时"也走事件通路，主循环结构更统一。常见的做法是定义 USEREVENT 值，用 set_timer 周期触发，在事件循环里处理，比如倒计时、NPC 巡逻状态切换。

对比三种时间方案：get_ticks 适合"记录时刻、手动差值"的精确控制；wait 适合一次性阻塞等待；set_timer 适合周期性事件。它们的单位都是毫秒，这是 SDL 的传统——1 秒 = 1000 毫秒，比起秒为单位的小数，毫秒整数在累加时不容易累积浮点误差。

4.3 Rect：碰撞检测的数学基础

Rect 是 Pygame 里最轻量也最重要的数据结构。它只是一个矩形对象，用 (left, top, width, height) 描述，但附带大量便捷属性：top、left、bottom、right、center、centerx、centery。Surface 有 get_rect() 方法，拿到与图像同尺寸的矩形，再配合 topleft 或 center 参数定位——这是把图放到指定位置的标准姿势。

player_rect = player_img.get_rect(topleft=(100, 200)) bullet_rect = bullet_img.get_rect(center=(bullet_x, bullet_y)) # 两矩形相交即视为碰撞命中 if player_rect.colliderect(bullet_rect): hit()

colliderect 做的是矩形相交判断：比较两矩形的左右边界和上下边界是否有重叠区间，本质是四次数值比较，速度极快。collidepoint 判断点是否落在矩形内，collidelist 一次和一列矩形做相交测试，适合子弹扫敌人列表。Rect 还提供 move() 返回新矩形、move_ip() 原地移动、clamp() 把矩形拉回另一矩形内，这些方法让碰撞后的位置修正变得很简短。

对于 2D 游戏，Rect 级碰撞精度通常足够。"看着没撞却被判定撞了"多半是因为图像有透明边缘，而 Rect 是完整包围盒——这是设计取舍，不是 bug。需要像素级碰撞可以先用 Rect 粗筛，再做像素遍历细判。精灵（Sprite）类也只是把 Surface、Rect 和 update 行为打包进一个类，配合 sprite.Group 统一调用 update() 和 draw(screen)，draw 内部仍然是逐个 blit，没有额外的性能魔法。

4.4 Transform 的旋转陷阱：旋转后图片为什么会"跳"

pygame.transform.rotate(surface, angle) 按角度逆时针旋转图片，很多人发现旋转后的图片变大了，贴着贴着就飘起来了。原因是：Surface 本质是矩形像素矩阵，旋转后原矩形的四个角会超出边界，Pygame 必须新建一个能覆盖全部结果的最小矩形 Surface，尺寸自然变大。按原坐标 blit，视觉上就出现位置偏移和抖动。

rotated = pygame.transform.rotate(img, 45) # 让旋转后的新矩形中心与原来的中心保持一致 new_rect = rotated.get_rect(center=old_rect.center) screen.blit(rotated, new_rect)

用 get_rect(center=...) 重新定位，让旋转前后中心一致，是做旋转动画的必修课。rotozoom(angle, scale) 同时处理旋转和缩放，内部做一次高质量重采样，效率低于单独 rotate；scale() 缩放是像素重采样，放大必然出现锯齿，这是位图的物理限制，与 Pygame 无关。

另一个容易踩的细节是：rotate 的参数是角度制，逆时针为正；而 rotozoom 的 scale 参数是浮点倍数，0.5 代表缩小一半。连续旋转时，绝不能用上次的旋转结果再次 rotate，而应该保存原图副本，每帧从原图转——否则连续重采样会让图像越来越模糊，这就是"转几圈之后画面糊了"的根源。

5. 避坑指南：五个最容易翻车的底层细节

5.1 窗口一闪而过，控制台直接退出

刚接触 Pygame 的脚本里，这个现象几乎必现。现象是：双击运行 py 文件，窗口弹出来不到一秒就消失，控制台也跟着退出。

原因是：代码创建了窗口却没写主循环，进程执行完最后一行，窗口随进程销毁。而 pygame.quit() 只是卸载模块，不会让窗口多停留哪怕一帧。还有一种隐蔽变体：IDE 里运行正常，双击运行就闪退——多半是代码里用了相对路径读取图片，双击时工作目录不是脚本所在目录，找不到资源抛异常退出。

解决：记住"窗口创建之后必须接一个无限循环"。用 running 标志时，确认循环的唯一出口是 QUIT 事件；把 sys.exit() 放在循环外统一收尾。涉及外部资源时，用 os.path.join(os.path.dirname(file), "assets/xxx.png") 基于脚本绝对路径拼资源路径，而不是依赖当前工作目录。

5.2 画面全黑，但代码逻辑看着全对

现象：fill 了背景、blit 了图片、draw 了图形，窗口却一片黑。

原因是：双缓冲模式下所有绘制都进了后备缓冲，display.flip() 或 update() 负责把它交换到屏幕。漏掉 flip，绘制结果永远停留在用户看不到的缓冲层。局部刷新时还有个变体：update(rect) 传入的矩形区域跟实际绘制坐标不一致，屏幕只刷新了没内容的部分，看起来也是"没更新"。

解决：主循环末尾检查是否有 flip/update。局部刷新时，把 update 参数与实际产生变化的矩形区域对齐。贪吃蛇这类游戏做局部刷新时，蛇头移出新格、蛇尾离开旧格，新旧两个矩形区域都要刷新，否则会留下残影。宁可多刷一点，不要刷错位置。

5.3 图片加载慢、blit 的时候特别吃 CPU

现象：游戏运行明显掉帧，尤其每帧都加载新图片的版本卡得不能动。

原因是：image.load() 加载的图片像素格式不一定与屏幕一致，blit 时 SDL 要逐像素把源格式转成目标格式，转换成本远高于拷贝本身。教程反复强调 convert() 就是为了把隐式开销转移到加载阶段付清。

解决：所有常驻图片在加载后立刻调用 convert()（无透明）或 convert_alpha()（有透明）；不要在循环内反复 load 图片，资源统一在初始化阶段载入内存。排查方法是打印 screen.get_bitsize() 和图片 Surface 的 get_bitsize() 对比，不一致就说明 blit 前会做格式转换；也可以用同一张图连续 blit 两次，第一次明显慢于第二次，就基本能确认是格式转换在拖后腿。

5.4 旋转动画越转越糊，位置还飘

现象：角色每帧旋转，画面抖动，清晰度肉眼可见地下降。

原因是：rotate() 每次生成新的 Surface，如果拿上一帧旋转结果继续旋转，连续重采样会累积失真；位置飘则是因为旋转后外接矩形尺寸变化，没有重新取 center。非 90 度倍数的旋转尤其明显，角度越接近 45 度，外接矩形扩张得越厉害。

解决：保存一份原始图片副本，每帧用原图 rotate，而不是用上一帧的结果继续转；blit 前用 rotated.get_rect(center=固定中心) 重新定位。调试时打印新旧 rect 的 size，你会看到旋转 45 度时尺寸明显变大——这就是"飘"的来源。如果是子弹这类大量旋转对象，可以考虑预先把几个固定角度的旋转结果缓存成列表，运行时直接查表，省掉每帧重复旋转的 CPU 开销。

5.5 按键"连跳"或移动失控

现象：按住方向键角色疯狂抖动，或按一次跳跃键连跳好几下。

原因是：输入读取方式混用。KEYDOWN 事件按下瞬间只触发一次，适合跳跃；get_pressed() 返回的是实时状态，适合持续移动。用 get_pressed() 写跳跃，按住键时每一帧都判定按下，跳跃被连续触发；用 KEYDOWN 写移动，系统按键重复会让移动一顿一顿。

解决：两类输入按语义分开处理——持续型动作（走、跑）读 key.get_pressed()，单次型动作（跳、冲刺、开火）用 KEYDOWN，必要时加 event.key 过滤避免其他键误触。还需要注意 event.mod 修饰键状态：比如检测 Shift 加速跑时，用 event.mod & pygame.KMOD_SHIFT 判断，而不是直接比较相等，因为可能有多个修饰键同时按下。

6. 设计取舍：为什么 Pygame 选择"薄"而不是"全"

Pygame 本质上是一层很薄的 SDL 封装，它刻意不做成引擎：没有场景图、没有物理引擎、没有内置 UI 系统，连碰撞都只提供矩形级别。对学习者来说，这个取舍是极大的优点——引擎的"完整"意味着框架先于逻辑，你还没搞懂主循环，就得先学会组件的生命周期；Pygame 的薄把一切摊在明面上：主循环自己写，状态自己存，绘制自己调。学得浅，但学得透。

性能上，"薄"反而是另一种胜利。Pygame 的热点路径全部在 C 层：blit 是位块传输，transform 是像素重采样，字体走 SDL_ttf，音频走 SDL_mixer。Python 只承担调度和游戏逻辑，而这两者恰好是按帧执行的轻量代码。想验证这个结论很容易：写个脚本，把 1000 个带透明通道的小 Surface 每帧依次 blit，观察帧率曲线的形状——你会发现前 100 个的开销远低于最后 100 个，因为 Python 层的循环调用成本成了瓶颈，而不是 C 层拷贝。这个对比能帮你理解"哪部分性能该优化 Python，哪部分换库都没用"。

理解了这一层，你就能判断 Pygame 适合什么：教学、2D 原型、Game Jam、轻量工具，它都是高效选择；需要骨骼动画、复杂物理、场景流管理的项目，换引擎是理性的工程决策，而不是背弃。回看这份教程的模块划分——display、Surface、event、time、Rect、transform——每一个都对应 SDL 的一个底层能力，没有一个是为"引擎"服务的抽象层。这种一一映射的关系，让 Pygame 成为理解游戏引擎底层原理的最佳入口。

我个人的习惯是，每次拿到一个游戏库，先画一张"数据从哪来、画到哪去、循环怎么转"的草图，再写第一行代码。这份教程提供的正是那张草图的每一个部件，把循环、像素、事件、时间这几根支柱立起来，剩下的绘图函数、字体渲染、精灵分组，都是在这张骨架上添肉。希望帮到你。

本文还有配套的精品资源，点击获取