简介：这是一份面向Python初学者与图形编程爱好者的Pygame烟花动画实践教程，围绕新年烟花展示场景，讲解从环境准备到完整代码实现的流程，帮助读者理解粒子系统、烟花发射与爆炸逻辑、颜色配置及背景音乐播放等基础图形界面应用技巧。压缩包共1个docx文件，大小约16KB，以图文讲解和可运行代码示例为主，便于按步骤阅读和动手复现。教程不仅给出完整示例，还拆解Particle与Firework类的职责划分，说明粒子生命周期、随机发射与爆炸触发等关键环节。目前已有143人学习，适合用作节日庆祝小程序练习或Pygame入门项目参考。读者可据此搭建带动态粒子和音效的烟花程序，并进一步调整粒子数量、发射频率、配色与音乐路径，形成自己的展示效果。
1. 一份能直接跑的 Pygame 烟花脚本，适合谁、能做什么
跨年夜里想做一个烟花效果，很多人第一反应是打开 AE 或者剪一段视频，但如果手上正好有 Python 环境，用Pygame写一个可交互、带音效的烟花动画反而更快——两百行以内的代码，就能得到一个跑在任何桌面系统上的粒子演示，还能按空格键自己发射。这份资源就是一套完整可运行的脚本：Particle粒子类负责位置、速度、角度、生命周期，Firework发射器类负责升空与爆炸，配合pygame.mixer播放背景音乐，屏幕上的烟花会不断随机升空、炸开、消散。
它适合两类人：刚学完 Python 语法、急需一个「能看到结果」的练手项目的新手；以及想把 Pygame 的事件循环、帧率控制、简单粒子系统一次性摸清的开发者。需要提前说清的是，这是个演示级工程，不是商业动画引擎——颜色、拖尾、并发数量都有明确的上限，理解它能做什么、不能做什么，比直接复制粘贴更重要。
2. 环境与工程骨架：先把窗口、时钟、音频通道立起来
动手改粒子之前，先把最外层的骨架搭稳。很多人炸在第一步不是代码写错，而是环境或初始化顺序有问题，后面所有调参都是在错误的地基上做。
2.1 依赖安装与版本边界
安装命令就一行，但要注意虚拟环境和 Python 版本。Pygame 的 2.x 系列对 Python 3.8 以上支持较好，如果你的环境还在 3.6 附近，建议先升级解释器而不是降级库。
# 建议在独立虚拟环境中操作，避免和其他项目互相污染 python -m venv venv # Windows 下激活 venv\Scripts\activate # macOS / Linux 下激活 # source venv/bin/activate # 安装 Pygame，加 --upgrade 防止残留旧版本 pip install pygame --upgrade # 验证安装：能打印出版本号才算通过 python -c "import pygame; print(pygame.version.ver)"这段命令里最关键的是最后那行验证。import pygame成功不代表音频子系统可用，但至少能排除「库根本没装到当前解释器」这种最常见的问题。要注意的是，如果你同时装了系统 Python 和多套虚拟环境，pip install装的位置和编辑器里选中的解释器经常不是同一个，表现就是编辑器提示ModuleNotFoundError、命令行却一切正常——遇到这种情况先查解释器路径，别急着重装。
--upgrade的作用是覆盖已有版本。旧版本里pygame.mixer.music的部分行为与新版略有差异，统一到较新的 2.x 可以减少「照着教程写却报错」的概率。
2.2 窗口、帧率与事件循环骨架
Pygame 程序的骨架永远是四段式：事件处理 → 逻辑更新 → 绘制 → 帧率控制。顺序不能乱，尤其是事件必须放在更新之前，否则这一帧内按下的按键要等到下一帧才生效，手感会明显发滞。
import pygame pygame.init() W, H = 800, 600 screen = pygame.display.set_mode((W, H)) pygame.display.set_caption("Fireworks Demo") # Clock 负责把循环速度钉在目标帧率上 clock = pygame.time.Clock() running = True while running: # 1) 事件处理：一次性消费本帧所有输入事件 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE: pass # 空格手动发射，第 4 章填进来 # 2) 逻辑更新：粒子位移、状态切换、生成新烟花 # 3) 绘制：先清屏再画，顺序反了会看到上一帧残影叠死 # 4) 提交绘制缓冲 pygame.display.flip() # 5) 帧率控制，返回值是距上一帧的毫秒数 dt_ms = clock.tick(60) pygame.quit()clock.tick(60)有两个作用：限制最高 60 帧，同时返回上一帧耗时。这个返回值很关键——它是后面做「帧率无关运动」的唯一依据。如果你的机器掉到 30 帧，而粒子的速度仍然按「每帧走 3 像素」计算，整个动画会突然慢一半，看起来像卡住。稳妥的写法是用dt_ms / 16.7作为缩放系数，让速度在不同帧率下保持一致。
pygame.display.flip()是双缓冲的交换操作。Pygame 默认使用双缓冲，你在内存 Surface 上画完，flip()才把它推到屏幕上。少了这一行，窗口会一片漆黑——这是新手最常见的翻车点之一。
2.3 音频通道初始化与失败兜底
音频是这份脚本里最容易「在别人机器上能响、在你机器上不响」的部分。核心原因是 Pygame 的 mixer 依赖底层音频设备，在没有声卡的环境（服务器、容器、部分 CI）里会直接抛异常。
import pygame pygame.init() # mixer 必须在 pygame.init() 之后、加载音乐之前单独初始化 try: pygame.mixer.init(frequency=44100, # 采样率，CD 音质标准 size=-16, # 负号表示有符号，16 表示 16 位 channels=2, # 2 = 立体声 buffer=512) # 缓冲区越小延迟越低，但更吃 CPU pygame.mixer.music.load("bgm.mp3") pygame.mixer.music.set_volume(0.5) # 0.0 ~ 1.0，背景音乐别盖过音效 pygame.mixer.music.play(-1, start=0.0) # -1 表示无限循环 except pygame.error as e: # 没有音频设备时降级为静音运行，而不是让整个程序崩掉 print("音频不可用，继续无声运行:", e)try/except这一层是必须的「后悔药」。我见过太多脚本因为mixer.init()失败就直接退出，导致在有声卡没权限的环境里完全跑不起来。降级到静音后，视觉效果照常，调试体验完全不同。
参数方面，buffer=512属于偏小的设置，延迟低但 CPU 占用略高；如果你的机器性能吃紧或者出现爆音，改成 1024 或 2048 会更稳，代价是音乐和画面之间会有轻微不同步。play(-1)的-1是循环次数，start=0.0是起始秒数，想让音乐从中间开始就改这个值。
文件格式上，pygame.mixer.music对 MP3 和 OGG 的支持最好，WAV 虽然也能播但体积大。路径建议用相对路径assets/bgm.mp3而不是绝对路径，否则把项目拷给别人就必然失效。
3. 粒子类拆解：位置、速度、角度、寿命四个参数怎么改才像烟花
骨架跑通之后，画面里的一切效果都归结到Particle这一个类上。原始脚本里这个类只有二十来行，但恰好踩中了粒子系统的几个经典坑，值得逐字段拆开看。
3.1 Particle 的字段设计与每帧更新顺序
先看一个可直接替换的完整实现：
import math import random import pygame class Particle: # __slots__ 省掉每个实例的 __dict__，几百个粒子时内存差异很明显 __slots__ = ("x", "y", "vx", "vy", "color", "size", "life", "max_life", "gravity", "damping") def __init__(self, x, y, color, speed=(2.0, 5.0), life=25, size=(2, 7)): self.x = float(x) self.y = float(y) self.color = color self.size = random.randint(*size) self.life = self.max_life = life angle = random.uniform(0, 2 * math.pi) v = random.uniform(*speed) # 三角函数只在构造时算一次，之后全部用分量叠加 self.vx = v * math.cos(angle) self.vy = -v * math.sin(angle) # 屏幕 y 轴向下，取负号才是"往上飞" self.gravity = 0.06 self.damping = 0.985 def update(self): self.vy += self.gravity # 重力只作用于竖直方向 self.vx *= self.damping # 阻尼模拟空气阻力 self.vy *= self.damping self.x += self.vx self.y += self.vy self.life -= 1 def draw(self, surface): if self.life <= 0: return # 半径随剩余寿命线性收缩，视觉上就是"燃尽" radius = max(1, int(self.size * self.life / self.max_life)) pygame.draw.circle(surface, self.color, (int(self.x), int(self.y)), radius)几个设计点值得说明。第一，坐标存float，只在draw()里取整。如果初始化就存整数，每帧的位移量小于 1 时会被反复截断成 0，粒子看起来会「抖」或者干脆不动。第二，角度和速度在构造时一次性转成vx/vy分量，而不是每帧重新算cos/sin——一百个粒子、六十帧、持续几十秒，三角函数的调用次数会被放大到几十万次，能省就省。第三，max_life单独存一份，绘制时的收尾效果全靠它做分母。
update()里的顺序也有讲究：先加重力、再乘阻尼、最后叠加到坐标上。如果把阻尼放在坐标更新之后，第一帧的初速度会不受影响，爆炸瞬间会有一个突兀的「顿挫」。
3.2 重力与阻尼：别再用 speed *= 0.95 了
原始脚本里那个self.speed *= 0.95是整套代码里最需要改的一行。它的问题在于：速度被当成标量做指数衰减，意味着无论粒子往哪个方向飞，都在匀速「刹车」，结果是粒子飞到一半就几乎停住，像被冻在空气里，完全没有烟花炸开后向下坠落的弧线。
正确的模型是把重力当成恒定加速度，把阻尼当成空气阻力的近似，两者分别作用在速度的两个分量上。这里给一份参数对照，方便按视觉效果反查：
| 参数 | 建议初值 | 作用 | 调大的效果 | 调小的效果 |
|---|---|---|---|---|
gravity | 0.06 | 每帧竖直加速度 | 下坠更快，接近「礼花弹」 | 下坠平缓，接近「太空感」 |
damping | 0.985 | 每帧速度保留比例 | 拖得更远，扩散面更大 | 衰减更快，爆点更集中 |
speed | (2.0, 5.0) | 初始速度区间 | 爆炸半径大，粒子易飞出边界 | 缩成一团，没有张力 |
life | 25 | 存活帧数 | 停留久，拖尾长 | 一闪即逝，节奏更利落 |
比较实用的组合是：外层大粒子用gravity=0.06, damping=0.99，内层碎屑用gravity=0.09, damping=0.97，两种颗粒混在同一个爆炸里，层次感会立刻出来。
如果你的机器无法稳定在 60 帧，需要把更新改成帧率无关。最省事的做法是把clock.tick(60)的返回值拿出来做缩放：
def update(self, dt_scale): # dt_scale = dt_ms / 16.7，60fps 时约等于 1.0 self.vy += self.gravity * dt_scale self.vx *= self.damping ** dt_scale self.vy *= self.damping ** dt_scale self.x += self.vx * dt_scale self.y += self.vy * dt_scale self.life -= 1阻尼那里用指数运算是有原因的：damping ** dt_scale保证无论拆成几帧，累计衰减量都一致，这是分辨率无关的写法。不追求极致精确的话，直接乘一次也够用，但在 30 帧的机器上会看到明显差异。
3.3 颜色、拖尾与 alpha 混合
原始的配色方案是random.choice从三种颜色里挑，问题是一次爆炸里所有粒子同色，炸出来像一个实心球，没有体积感。行业内的常见做法是给每次爆炸定一个基础色相，然后让每个粒子在色相上做小幅度扰动：
import colorsys def hue_color(hue, sat=0.9, val=1.0): """把 0~1 的色相转成 RGB 元组，sat/val 控制鲜艳度和亮度""" r, g, b = colorsys.hsv_to_rgb(hue % 1.0, sat, val) return (int(r * 255), int(g * 255), int(b * 255)) # 一次爆炸的所有粒子共享同一个 base_hue，只做 ±0.03 的抖动 base_hue = random.random() p = Particle(x, y, hue_color(base_hue + random.uniform(-0.03, 0.03)))用 HSV 而不是 RGB 的好处是，色相偏移和亮度调节是解耦的。sat=0.9让颜色足够饱和，不会灰扑扑；val=1.0保证在黑色背景上足够亮。想要金色、紫色、青绿色这类「高级感」配色，直接调base_hue就行，不用去凑 RGB 三元组。
拖尾效果是第二个视觉分水岭。原始代码每帧screen.fill(BLACK)全清，粒子身后干干净净，动起来像一个个独立的点。改成半透明覆盖，残影自然就出来了：
# 循环外创建一次，千万别放进 while 里每帧 new fade = pygame.Surface((W, H)) fade.fill((0, 0, 0)) fade.set_alpha(28) # 主循环内，替代 screen.fill(BLACK) screen.blit(fade, (0, 0))set_alpha(28)意味着每帧擦掉大约 11% 的亮度，残影大约能留 10 帧左右。这个值调到 15 以下拖尾会长到糊成一片，调到 60 以上基本等于全清。28 是个比较稳的中间值。
注意一个边界：pygame.draw.circle本身不支持半透明混色，粒子画出来永远是不透明的实心圆。想要真正的加色发光效果，得把粒子画到一张独立的Surface上，再用screen.blit(glow, (0, 0), special_flags=pygame.BLEND_RGBA_ADD)叠加。这是进阶玩法，但代价是每帧多一次全屏 blit，粒子数超过两千时会明显掉帧。
4. 发射器与爆炸逻辑：Firework 状态机与每帧调度
粒子只是砖头，真正决定「像不像烟花」的是Firework这一层的调度逻辑。原始脚本用一个particles列表加隐式判断来管理状态，逻辑一多就容易自相矛盾，改成显式状态机会清楚很多。
4.1 上升—爆炸—回收三态
一枚烟花从发射到消失，严格来说是三个状态：上升、爆发、结束。用枚举把状态标出来，每个状态只处理自己的事：
class Firework: RISE, BURST, DONE = 0, 1, 2 def __init__(self, x, target_y, color): self.state = Firework.RISE self.color = color self.particles = [] self.target_y = target_y # 上升的主角也是一个粒子，只是寿命设得极长，靠状态来终结 self.rocket = Particle(x, H, color, speed=(0, 0), life=10**6, size=(3, 4)) self.rocket.vx = random.uniform(-0.6, 0.6) # 轻微横向漂移 self.rocket.vy = -random.uniform(6.0, 9.0) # 初速度向上 self.rocket.gravity = 0.09 # 上升段重力略强，才有减速感 def update(self): if self.state == Firework.RISE: self.rocket.update() # 速度由负转正，或者已越过目标高度，就该炸了 if self.rocket.vy >= -0.5 or self.rocket.y <= self.target_y: self._explode() elif self.state == Firework.BURST: for p in self.particles: p.update() # 原地过滤已死亡的粒子，避免列表无限增长 self.particles = [p for p in self.particles if p.life > 0] if not self.particles: self.state = Firework.DONE return self.state def _explode(self): self.state = Firework.BURST # 由 4.2 节补充粒子生成逻辑这里有两个容易写错的条件。判断「该炸了」用的是vy >= -0.5，因为火箭初速度是负的（向上），重力会把它慢慢拉回正值，-0.5这个阈值代表「已经几乎停在最高点」。如果直接判断vy > 0，火箭会先下坠一小段再爆炸，看起来像炸歪了。
life=10**6是一个「伪无限寿命」的写法。上升粒子的存活时间由状态机控制，不需要靠life递减来回收，所以给一个足够大的值让它不会自然消亡。这是一种取舍：省掉了一套独立的火箭类，代价是得记住这个魔数。
4.2 爆炸粒子的分布：均匀随机其实不均匀
_explode()里最容易被低估的是速度的采样方式。如果直接v = random.uniform(0, vmax)，粒子会明显向中心聚集——因为速度小的粒子分布密度更高，炸出来的形状是一个中间发白的实心团，而不是均匀的球壳。
正确的做法是等面积采样，用平方根把分布「往外推」：
import math, random def _explode(self): base_hue = random.random() vmax = random.uniform(4.5, 7.5) # 每次爆炸半径略有随机 count = random.randint(70, 120) # 粒子数也随机，避免整齐划一 for _ in range(count): # sqrt 采样：保证单位圆内的点密度均匀，炸出来是球壳而非实心球 v = vmax * math.sqrt(random.random()) angle = random.uniform(0, 2 * math.pi) color = hue_color(base_hue + random.uniform(-0.03, 0.03)) p = Particle(self.rocket.x, self.rocket.y, color, speed=(0, 0)) # 直接覆盖速度分量，绕开构造函数里的随机角度 p.vx = v * math.cos(angle) p.vy = -v * math.sin(angle) p.life = p.max_life = random.randint(30, 60) p.damping = 0.97 self.particles.append(p) self.state = Firework.BURSTvmax * math.sqrt(random.random())这一行是整段代码的核心。它保证速度的平方在[0, vmax²]上均匀分布，也就是单位时间内落在每个环形区域里的粒子数相等，视觉效果是干净的外扩球壳。不加平方根，中心会明显糊成一坨。
p.life设成随机区间而不是固定值，是为了让爆炸有「逐渐熄灭」的层次感。如果所有粒子同时消失，会看到整个烟花「啪」地一下集体不见，非常出戏。
4.3 发射频率与性能上限
原始代码里那句random.random() < 0.05标注的是「每秒约有 5% 的概率发射新烟花」，这个说法其实不准确。主循环跑在 60 帧下，每一帧都做一次判断，所以实际速率是0.05 × 60 ≈ 3发每秒，而不是 5%。这个误标很典型——概率是每帧的，速率是每秒的，中间差一个帧率系数。
想让节奏可控，用累计时间而不是概率：
spawn_interval = 0.8 # 每 0.8 秒自动发射一枚 spawn_timer = 0.0 while running: dt_ms = clock.tick(60) dt = dt_ms / 1000.0 spawn_timer += dt if spawn_timer >= spawn_interval: spawn_timer = 0.0 x = random.randint(100, W - 100) target = random.randint(80, H // 2) fw = Firework(x, target, hue_color(random.random())) fw.update() # 触发一次上升态推进，避免首帧静止 fireworks.append(fw)用时间而不是帧数，好处是换台机器、换个帧率，发射节奏完全一致。target限制在屏幕上半部分，是为了让爆炸点落在视觉中心区，如果允许target_y取到屏幕底部，烟花的碎片会有一半飞出画面。
性能上限方面，粒子的总数量是所有效果的第一约束。pygame.draw.circle每个粒子一次调用，加上列表遍历和过滤，在普通办公本上大约 800～1200 个粒子还能维持 60 帧，超过之后开始掉。加一道闸门：
MAX_PARTICLES = 1200 total = sum(len(f.particles) for f in fireworks) if total > MAX_PARTICLES: # 超限时跳过本次自动发射，但手动空格不受影响 pass else: # 正常发射逻辑 ...注意sum(len(...) for ...)本身也是 O(烟花数) 的开销，烟花数量稳定在个位数时无所谓，如果你想做几百枚同屏的极限测试，得改成维护一个全局计数器，在粒子的增删处同步加减。
5. 避坑排查：画面、音频、逻辑三类的五个高频翻车点
下面这五条基本覆盖了照着脚本抄下来之后会遇到的绝大多数问题，每条按「现象 → 原因 → 解决」走一遍。
5.1 画面与音频相关的三个现象
现象一：窗口正常弹出，但里面一片漆黑，什么都看不到。
原因排在最前面的是pygame.display.flip()漏掉了。Pygame 用双缓冲，所有绘制都发生在内存里的 Surface 上，不调flip()就永远不会推到屏幕。第二种可能是screen.fill()写在了绘制之后，把刚画好的东西直接盖掉。第三种比较隐蔽：绘制坐标是浮点或负数，pygame.draw.circle会静默不画，不报错。
解决：先确认flip()在循环体末尾；再检查fill()的位置；最后在draw()里打印一次(self.x, self.y)，如果坐标是nan，说明初始化时speed传了(0, 0)又立刻做了除法，检查构造函数。
现象二：程序能跑，但完全没有声音，控制台也没有报错。
原因通常有三个。第一，音乐文件路径不对，但load()在部分版本下不会即时抛异常，要到play()才失败，而且失败信息容易被忽略。第二，音频设备在容器或远程桌面环境里不可用，mixer.init()静默降级。第三，文件格式不被支持，比如用了某些编码的 MP3。
解决：把load()和play()都用try/except包起来并打印异常；确认文件路径是相对于脚本运行目录而不是脚本文件所在目录——这是个经典陷阱，在 IDE 里点运行和命令行里python xxx.py的工作目录可能不同。稳妥写法是用os.path.join(os.path.dirname(__file__), "assets", "bgm.mp3")拼绝对路径。
现象三：粒子炸开后原地停住，像被冻在空气里，没有下坠的弧线。
原因就是前面 3.2 节说的self.speed *= 0.95。速度被当作标量做指数衰减，几帧之后就趋近于零，位移量小于 0.5 像素，取整后变成不动。
解决：拆成vx/vy两个分量，阻尼乘在分量上，重力加在vy上。改完之后如果觉得下坠还是太快或太慢，回到 3.2 节的参数表调gravity，别再去动阻尼。
5.2 逻辑与性能相关的两个现象
现象四：跑一两分钟之后帧率从 60 掉到个位数，越跑越卡。
原因是粒子列表只增不减。原始脚本靠particles.remove(particle)在遍历时删除元素，这在 Python 里是危险操作——遍历中修改列表会跳过元素，导致部分死亡粒子永远留在列表里，累积成几千上万个，每帧都要遍历和绘制。
解决：不要在for循环里remove，改成遍历后统一过滤：self.particles = [p for p in self.particles if p.life > 0]。同时检查是不是在while里pygame.Surface(...)新建了对象——半透明遮罩层必须放在循环外创建一次，每帧新建一张 800×600 的 Surface 是性能杀手。
现象五：所有烟花都从屏幕底部同一高度升空，而且几乎同时消失。
原因在坐标系。屏幕坐标的 y 轴向下，0在顶部，H在底部。上升意味着 y 减小，所以初速度必须是负的（vy = -random.uniform(6, 9)）。如果写成正值，火箭会从屏幕底部一直往下掉，看起来就是「全部消失」。判断爆炸时同理，vy >= -0.5表示速度已经由负转正或接近零，如果写成vy <= -0.5，会永远不触发爆炸。
解决：把「向上 = 负 y 速度」这条写在注释里。另外初始 x 坐标如果用random.randint(0, screen_width)，边缘的烟花会有一半在画外，改成random.randint(100, W - 100)留出边距。
补充一个不属于 bug 但很影响观感的问题：如果自动发射和空格手动发射都没做数量上限，按住空格不放会瞬间堆出几十枚烟花，画面直接白屏然后卡死。手动发射路径也要走一遍MAX_PARTICLES检查。
6. 进阶：把硬编码的烟花改成配置驱动的演出脚本
代码跑通之后，最想做的事通常是「换个节奏、换套配色」，而原始脚本把这些全写死在构造函数里，每次改都要翻代码。我一般会把它抽成一份配置，主循环只负责按时间轴读取和调度：
import json SHOW = { "duration": 60, "bgm": "assets/bgm.mp3", "volume": 0.5, "auto_interval": 0.8, "max_particles": 1200, "palette": [0.00, 0.08, 0.33, 0.55, 0.75, 0.92], # 色相环上均匀取样 "burst_size": [70, 120], "trail_alpha": 28, } def pick_color(cfg): # 从调色板里挑一个色相，再加抖动，避免每次颜色都一样 base = random.choice(cfg["palette"]) return hue_color(base + random.uniform(-0.03, 0.03)) def load_show(path): # 外部 JSON 覆盖默认值，方便不改代码切主题 with open(path, "r", encoding="utf-8") as fp: SHOW.update(json.load(fp)) return SHOW这份配置的价值在于把「演出参数」和「渲染逻辑」分开了。palette用色相环上的等距取样，是因为相邻色相之间色差足够，同屏出现时不会糊在一起；trail_alpha单独拎出来，是因为拖尾长度和屏幕分辨率强相关，换到 1920×1080 的窗口上，28 这个值会让残影看起来短很多，得相应调小。
配置化的第二个好处是可以做简单的演出序列：把整段 60 秒切成若干段，每段指定不同的调色板和发射间隔，跨年倒数那几秒突然加密发射，视觉冲击力比均匀撒点强得多。实现上不用引入复杂的时间轴库，一个按累计时间走的游标就够了：
timeline = [ (0, 1.2, [0.00, 0.55]), # 0~20 秒：慢节奏，红青两色 (20, 0.8, [0.08, 0.33, 0.75]), # 20~45 秒：中速，三色轮换 (45, 0.25, [0.00, 0.08, 0.33, 0.55, 0.75, 0.92]), # 最后 15 秒：全色齐发 ] def current_stage(t): for start, interval, palette in reversed(timeline): if t >= start: return interval, palette return timeline[0][1], timeline[0][2]reversed()是关键，它保证时间往后走时总是命中「最近一个已经开始的阶段」，不用写一堆if/elif区间判断。
最后说一个验证技巧，比肉眼盯着屏幕靠谱得多：在固定的随机种子下跑 300 帧，然后pygame.image.save(screen, "check_300.png")存一张图。改完参数后对比这张图，能立刻看出爆炸半径、拖尾长度、配色有没有意外变化。我在改粒子参数时被「看起来差不多但实际半径小了一圈」坑过不止一次，肉眼在两秒的动画里根本分辨不出来。
从那以后我每次动手改粒子参数前，都会先把种子固定下来存一组基准图，改完再跑一遍对比，确认差异是自己想要的那一处，而不是顺手把别的效果也带歪了。希望帮到你。
本文还有配套的精品资源，点击获取
