1. 先想清楚要做成什么样，再动手写第一行 Python

很多人搜“Python 代码雨”，心里想的其实是电影里那种绿色字符往下淌的画面。但真正动手时，第一行代码就开始纠结：用什么画？要不要装库？为什么我写出来的效果像一堆静止的乱码在闪。这篇就把我用 Python 复刻这套视觉效果的全过程拆开讲，从方案选型、数据结构、渲染顺序一直到最后调参，末端给两份可以直接跑起来的完整代码——一份 pygame 版，一份纯标准库 tkinter 版。你手里电脑上大概已经装好了 Python，看完挑一份复制就能看到东西动起来。

先说清楚这件事的边界。所谓“代码雨”，本质不是文字动画，而是一列一列竖直排列的字符，各自以不同速度下落，每列带一条由亮到暗的拖尾，字符内容还会随机变化。它不涉及任何算法难点，难点全在“怎么把这几百上千个字符按正确的位置、正确的亮度、正确的时机画到屏幕上，还能稳住 60 帧”。这就决定了工具选型的优先级——渲染方式的批量绘制能力，远比库的知名度重要。

我见过不少人第一版是拿print加time.sleep在终端里刷屏，跑起来整屏往下滚，观感完全不对。原因很简单：终端的换行是“推上去”，不是“画上去”，你没法把某一格的字符单独改成暗色。想做出拖尾和渐变，必须有一个能按坐标画字的画布。搞明白这一层需求，后面的选择就顺理成章了。

适合谁看：会写 Python 基础语法、知道函数和类是什么就够，不需要任何图形学背景。如果你只是想找段代码复制跑一下，第 3 节的完整代码直接拿走；如果你想弄明白每一行参数为什么这么设、屏幕卡顿怎么救、换台机器为什么字全挤在一起，那从头看更省事。

2. 方案选型：三种实现路线的取舍

2.1 pygame、tkinter、终端库的横向对比

摆在我面前的有三条路，我当时都试了一遍，下面是实测下来的对比，供你按自己的场景挑：

我最后选 pygame 做主方案，理由不是“它最强”，而是它把离屏绘制这件事做得最省心。pygame 里一个Surface就是一块像素缓冲，你可以先把一个字符渲染成一张小图缓存起来，之后每帧只是把这张小图往画布上贴，贴一千次也就几毫秒。tkinter 的 Canvas 每次delete("all")再重建几千个 item，开销就上去了，还得手动管理 canvas id，一旦泄漏就是内存缓慢上涨。

至于终端方案，我建议只在最极端的环境下用——比如你只能 SSH 到一台什么都不让装的机器上。真要在终端里做，也得靠 curses 的addstr指定行列，能做出个粗糙的雏形，但没有颜色渐变，视觉效果差得远。

2.2 把“炫酷”这个模糊的词拆成可实现的图层

“炫酷”是个没法直接编码的词。我的做法是把它拆成四个可以量化的图层，每一层单独实现、单独调参：

第一层是网格。屏幕上字符不是随便放的，而是严格对齐到一个单元格矩阵里，列宽等于字符宽度，行高等于字体的行高。这一层决定了画面的“秩序感”，一旦网格不整齐，看起来就像故障而不是效果。

第二层是下落。每一列有一个虚拟的“头部位置”，按各自的速度往下推进。速度必须逐列随机，如果所有列同速，画面会变成整体平移的横条，瞬间失去灵魂。

第三层是拖尾。头部后面的若干个格子，颜色从亮绿逐渐过渡到接近背景的深绿。这一层是“像雨”的关键，没有渐变就只是一排排跳动的字。

第四层是字符刷新。每个格子里的字符会以一定概率被换成新的随机字符，模拟“数字在流动”的感觉。刷新太快是雪花屏，太慢是静态文字墙。

把这四层分开想之后，代码结构自然就出来了：一个二维字符数组管内容，一个列对象数组管位置和速度，一个渲染函数负责按“距离头部的格数”算亮度。剩下的全是调参数。

2.3 为什么不用“画完再整体淡化”的经典写法

网上流传最广的写法是另一种思路：每帧在整块画布上盖一层半透明黑，让上一帧的内容自然变暗，然后再画新的字符。代码极短，十几行就能跑，我第一次也是这么写的。

但它有两个绕不过去的毛病。一是颜色会脏。绿色被黑色按 alpha 混合多次之后，拖尾会往灰绿、土黄的方向偏，尤其在纯黑背景上，末端会出现一层说不清的杂色。二是拖尾长度不可控。淡化速度由那层黑色的 alpha 决定，你想让某一列尾巴长一点、某一列短一点，根本做不到，所有列只能共用同一个衰减率。

我最终换成了“按深度算亮度”的方案。虽然多写了几十行，但换来的是：拖尾长度逐列可调、颜色渐变可以精确指定起止色、头部能单独高亮成接近白色的亮绿。这个取舍在我看来非常值——视觉效果的可控性，全靠这里。

3. 核心细节拆解：五个决定成败的关键点

3.1 每列独立的速度与相位，是“雨感”的来源

如果你只从这篇文章里记住一件事，那应该是这一条：随机化必须发生在列的维度上，而且必须包含初始相位。

速度好理解，每列给一个 6 到 20 行/秒之间的随机值。相位指的是每列初始的头部位置，必须让它在屏幕上方之外随机散布，比如random.uniform(-rows, 0)。如果不做相位随机，所有列从同一条水平线同时出发，第一秒钟你会看到一排字齐刷刷往下掉，像阅兵。

这里还有个容易忽略的细节：位置要用浮点数存，不要用整数。用整数的话，速度是 6 行/秒，60 帧下每帧只前进 0.1 格，取整之后十帧才动一格，看起来是卡顿的跳跃。用浮点数累积、只在绘制时取整，视觉上就是平滑的连续下移。

# 位置存浮点，绘制时取整，这是平滑滚动的前提 self.head += self.speed * dt # dt 是秒 end = int(self.head) # 只在画的时候取整

3.2 拖尾长度：短了像跳蚤，长了像色块

拖尾长度我用“格子数”来表示，随机范围 10 到 28。这个数字不是拍脑袋定的，得跟屏幕行数挂钩。以 720p、字号 20 为例，整屏大概 36 行，拖尾 10 格意味着尾巴占屏幕高度的四分之一多一点，看起来是一段清爽的短雨；拖尾 28 格几乎贯穿全屏，那就是连绵不断的长雨。

我实测下来，如果拖尾超过屏幕行数，视觉上会退化成“整列常亮”，因为尾巴一直没离开屏幕，新的雨头又接上来，看起来就是一根竖着的亮条在闪。所以调参时记住一条经验：拖尾上限不要超过屏幕总行数的一半。

亮度映射我用了 8 个等级，把拖尾从头部到末端线性映射过去：

depth = end - r # 距离头部几格，0 就是头部 if depth == 0: level = LEVELS # 头部最高亮 else: level = int((1.0 - depth / col.tail) * (LEVELS - 1))

为什么是 8 级而不是 256 级？因为每多一级，就要多缓存一批字形图。8 级 × 大约 90 个字符 = 720 张小图，内存占用可以忽略；而人眼在这种高速下落的画面上根本分辨不出 8 级和 32 级的差别。用离散等级换缓存命中率，是这类效果里非常划算的优化。

3.3 字符刷新率：一秒改多少次才“像数字在流动”

刷新率这个参数最玄学。我最初每帧把所有格子全部重新随机一遍，60 帧下等于每秒变 60 次，结果是满屏雪花，眼睛疼。后来改成每秒每个格子有 0.3 到 0.5 的概率被替换，瞬间就对了——你会看到零零星星几个字符在闪，剩下的保持稳定，像电影里那种“偶尔跳一下”的感觉。

实现上别写成“遍历每个格子掷骰子”，那样是 2000 多次随机调用。用总量控制的写法更省：

total = rows * cols n = int(total * MUTATE_RATE * dt) # dt 已换算成秒 for _ in range(n): r = random.randrange(rows) c = random.randrange(cols) grid[r][c] = random.choice(CHARSET)

这里有个小问题值得说：随机取格子是有可能重复取到同一格的，实际刷新量会略少于 n。对视觉效果毫无影响，不值得为此引入集合去重——那反而更慢。

注意：刷新率跟帧率是解耦的。如果你把 FPS 从 60 降到 30，刷新量的公式里乘了 dt，每秒的刷新总次数保持不变，画面观感不会因为降帧而变慢，只是变卡。这个设计在调性能的时候能救命。

3.4 头部高亮：一个像素级的细节，决定“高级感”

很多复刻版本通篇只有一种绿色，看起来就是一堆绿字往下掉。真正的观感差距在于头部那一格——它应该是接近白色的浅绿，比如(215, 255, 235)，跟后面的正绿拉开明显对比。这一格是整个画面的视觉焦点，它在动，你的眼睛就会跟着它走。

我一开始担心头部太亮会刺眼，实测下来恰恰相反：正绿(0, 255, 95)在纯黑背景上的亮度已经很高了，头部再亮一档不会难受，反而让“雨头”这个结构清晰起来。如果你用的是偏冷的绿色，头部可以往青白方向偏，比如(200, 255, 255)，气质会更“冷”。

3.5 时间步长：拖动窗口之后画面突然暴走的原因

一个新手几乎必踩的坑：用固定的位移量累加位置，也就是head += 2这种写法。这样写在同一台机器上没问题，换台性能差一点的机器，帧率从 60 掉到 30，雨就变成了半速；更糟的是你拖动一下窗口，主循环被阻塞几百毫秒，恢复的瞬间积累的时间没被处理，画面会突然“暴走”一下。

正确做法是每帧取实际经过的时间，乘进位移里：

dt = clock.tick(FPS) / 1000.0 # 毫秒转秒 dt = min(dt, 0.05) # 上限截断，防暴走

那个min(dt, 0.05)是保命的。窗口被拖动、系统切到别的程序、笔记本合盖再打开，这些情况下 dt 可能是好几秒。不截断的话，所有列一次性往下冲几百格，画面直接飞出去，用户以为程序崩了。截到 50 毫秒，最坏情况就是画面顿一下，逻辑不会乱。

4. 完整实现：pygame 版逐段拆解

4.1 环境准备与三个容易翻车的准备动作

依赖只有 pygame 一个，装完就完：

python -m pip install pygame

装完先做三件事，能省掉后面一半的排查时间。

第一，确认 pygame 能正常初始化。跑一下python -c "import pygame; pygame.init(); print(pygame.version.ver)"，能打印出版本号就说明底层库没问题。如果是 Linux 无桌面环境，pygame.display.set_mode会直接报错，那就老老实实用 tkinter 版或者别折腾了。

第二，确认字体。这是最容易翻车的一环，下一小节单独讲。

第三，把窗口尺寸设成你要录屏的分辨率。我一开始用 800×600 做原型，效果满意，改成 1920×1080 录屏时发现列数变了、整体密度完全不是那个味，只能重新调一遍参数。所以先定最终分辨率，再调参。

4.2 字体加载：为什么你的字全挤在一起了

pygame.font.Font(None, 20)会用 pygame 的默认字体，而默认字体不是等宽的。这意味着“i”和“W”渲染出来的宽度不一样，你按固定列宽去摆位置，行与行之间就会错位，画面上看起来像字符在互相挤压。

解决办法是加载一个等宽字体，并且用M的宽度作为列宽基准：

def load_font(size): for name in ("consolas", "couriernew", "dejavusansmono", "menlo", "monaco"): path = pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size)

pygame.font.match_font会按名字去系统字体目录里找，找到就返回路径。列表里放了 Windows 的 consolas、macOS 的 menlo、Linux 常见的 dejavusansmono，三个平台基本都能命中一个。全都找不到时回退到默认字体，这时候就得接受轻微错位，或者自己下一个等宽 TTF 文件，把FONT_FILE指向它。

列宽和行高这么算：

cell_w = max(1, font.size("M")[0]) cell_h = font.get_height() cols = max(1, WIDTH // cell_w) rows = HEIGHT // cell_h + 1

行数那个+1是有意为之。最后一行可能只露出半个字高，不加一的话底部会留一条黑边，雨往下落时看起来像被裁掉了。

4.3 字形缓存：把 60 帧从不可能变成轻松

这是性能上最关键的一段。如果你每帧对每个可见字符都调一次font.render，那是每秒上万次文本渲染，CPU 直接拉满，帧率掉到个位数。

正确做法是把“字符 + 亮度等级”当作缓存键，渲染一次存起来，之后只做 blit：

class GlyphCache: def __init__(self, font, levels=8): self.font = font self.levels = levels self._cache = {} @staticmethod def _mix(c1, c2, t): return ( int(c1[0] + (c2[0] - c1[0]) * t), int(c1[1] + (c2[1] - c1[1]) * t), int(c1[2] + (c2[2] - c1[2]) * t), ) def get(self, ch, level): key = (ch, level) surf = self._cache.get(key) if surf is None: if level >= self.levels: color = HEAD_COLOR else: color = self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf = self.font.render(ch, True, color) self._cache[key] = surf return surf

_mix做的是两个 RGB 颜色之间的线性插值。拖尾末端用(0, 50, 18)这种深橄榄绿，中间过渡到正绿(0, 255, 95)。注意末端色别直接用纯黑(0,0,0)，虽然视觉上差不多，但纯黑在不同显示器上会有色阶断层，用一点点绿反而是更稳的做法。

缓存建好之后，一帧的绘制就变成了纯粹的贴图操作。实测同样 2000 个可见字符，不做缓存是 8 帧，做了缓存稳定 60 帧，CPU 从 90% 多降到 15% 左右。

4.4 主循环与绘制顺序

绘制顺序在这里很讲究。我一开始是先算所有列的新位置再统一画，结果发现重叠的列会出现“后面的盖住前面的”这种自然效果，其实是对的；但如果你先画暗的再画亮的，观感更通透。所以我的循环是先遍历列、在列内部先算头部位置、再按由暗到亮的顺序画，也就是从拖尾末端往头部画：

for c, col in enumerate(columns): col.head += col.speed * dt end = int(col.head) start = end - col.tail for r in range(start, end + 1): # 从小到大，末尾暗、头部亮 if 0 <= r < rows: depth = end - r level = LEVELS if depth == 0 else int((1.0 - depth / col.tail) * (LEVELS - 1)) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h))

因为行号是从上往下递增的，而头部在下面，所以从头部的角度往回看，末端在上面。这个顺序天然就是“先画上面暗的、最后画下面亮的”，重叠时亮色压在上面，视觉上更立体。

列的回收也在这段里做。判断条件是整条尾巴都跑出屏幕底部，也就是头部位置减去拖尾长度大于总行数。这时候重新随机速度、拖尾和初始位置，让这一列从顶部重新开始，画面就能无限循环下去。

4.5 完整可运行代码

把上面所有片段拼起来，这里是完整版本，复制存成rain.py直接跑：

import random import sys import pygame # ---------------- 参数区 ---------------- WIDTH, HEIGHT = 1280, 720 FPS = 60 FONT_SIZE = 20 FONT_FILE = None # 指定等宽 TTF 路径，留空则自动查找 BG_COLOR = (0, 0, 0) HEAD_COLOR = (215, 255, 235) BODY_COLOR = (0, 255, 95) TAIL_COLOR = (0, 50, 18) CHARSET = ( "0123456789" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz" "!@#$%^&*()_+-=[]{}<>/\\|" ) LEVELS = 8 # 亮度分级数 MUTATE_RATE = 0.35 # 每秒每个格子被刷新的概率 def load_font(size): if FONT_FILE: return pygame.font.Font(FONT_FILE, size) for name in ("consolas", "couriernew", "dejavusansmono", "menlo", "monaco"): path = pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size) class GlyphCache: def __init__(self, font, levels=LEVELS): self.font = font self.levels = levels self._cache = {} @staticmethod def _mix(c1, c2, t): return ( int(c1[0] + (c2[0] - c1[0]) * t), int(c1[1] + (c2[1] - c1[1]) * t), int(c1[2] + (c2[2] - c1[2]) * t), ) def get(self, ch, level): key = (ch, level) surf = self._cache.get(key) if surf is None: if level >= self.levels: color = HEAD_COLOR else: color = self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf = self.font.render(ch, True, color) self._cache[key] = surf return surf class Column: __slots__ = ("head", "speed", "tail") def __init__(self, rows, initial=False): self.tail = random.randint(10, 28) self.speed = random.uniform(6.0, 20.0) self.head = random.uniform(-rows, 0) if initial else random.uniform(-self.tail, 0) def reset(self): self.tail = random.randint(10, 28) self.speed = random.uniform(6.0, 20.0) self.head = random.uniform(-self.tail, 0) def main(): pygame.init() screen = pygame.display.set_mode((WIDTH, HEIGHT)) pygame.display.set_caption("Code Rain") clock = pygame.time.Clock() font = load_font(FONT_SIZE) cell_w = max(1, font.size("M")[0]) cell_h = font.get_height() cols = max(1, WIDTH // cell_w) rows = HEIGHT // cell_h + 1 grid = [[random.choice(CHARSET) for _ in range(cols)] for _ in range(rows)] columns = [Column(rows, initial=True) for _ in range(cols)] glyphs = GlyphCache(font) running = True while running: dt = min(clock.tick(FPS) / 1000.0, 0.05) for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.KEYDOWN: if event.key in (pygame.K_ESCAPE, pygame.K_q): running = False elif event.key == pygame.K_F11: pygame.display.toggle_fullscreen() for _ in range(int(rows * cols * MUTATE_RATE * dt)): grid[random.randrange(rows)][random.randrange(cols)] = random.choice(CHARSET) screen.fill(BG_COLOR) for c, col in enumerate(columns): col.head += col.speed * dt end = int(col.head) for r in range(end - col.tail, end + 1): if 0 <= r < rows: depth = end - r if depth == 0: level = LEVELS else: level = max(0, int((1.0 - depth / col.tail) * (LEVELS - 1))) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h)) if end - col.tail > rows: col.reset() pygame.display.flip() pygame.quit() sys.exit(0) if __name__ == "__main__": main()

按 ESC 或 Q 退出，F11 切全屏。有人问能不能用 F11，实测在部分缩放设置下切全屏会导致画面模糊，因为 pygame 是把你的窗口内容拉伸上去的，不是重新按全屏分辨率渲染。追求清晰的话，直接把WIDTH, HEIGHT设成屏幕原生分辨率，全屏时用pygame.FULLSCREEN标志创建窗口。

4.6 调参速查表

参数就那么几个，但每个管什么得心里有数，不然改一处崩三处：

我个人的常用组合是：1080p 下FONT_SIZE=18、速度 8~22、拖尾 12~32、刷新率 0.3。这套参数在录屏时密度刚好，既不会密到看不清，也不会稀到像在下毛毛雨。

5. 不装第三方库的 tkinter 版本

5.1 换思路：没有 Surface，就得靠 Canvas 硬扛

有些环境就是装不了第三方包，比如公司电脑权限受限，或者你只是想把脚本丢给同事双击就能跑。这时候 tkinter 是唯一选择，但它得换一套实现思路。

pygame 有离屏 Surface，我可以先把字符渲染好缓存起来。tkinter 的 Canvas 没有这个东西，每个字符都必须作为独立的 item 存在。所以只能接受“每帧清空重画”，把开销压到最低的办法是：控制字符总量、降低帧率。

我实测下来，900×600 的窗口、14 号字、大约 1600 个可见字符，50 毫秒一帧（20 帧/秒）是能跑顺的，再往上就明显卡顿。如果你把窗口拉大或者字号调大，得相应地降帧。

5.2 完整代码

import random import tkinter as tk W, H = 900, 600 CELL_W, CELL_H = 14, 20 FONT = ("Consolas", 14) DELAY = 50 # 毫秒，约 20 帧 CHARSET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ@#$%&*" BG = "#000000" COLOR_HEAD = "#d4ffe8" COLOR_BODY = "#00ff5f" COLOR_TAIL = "#00330f" def hex_to_rgb(h): return int(h[1:3], 16), int(h[3:5], 16), int(h[5:7], 16) def blend(h1, h2, t): r1, g1, b1 = hex_to_rgb(h1) r2, g2, b2 = hex_to_rgb(h2) return "#%02x%02x%02x" % ( int(r1 + (r2 - r1) * t), int(g1 + (g2 - g1) * t), int(b1 + (b2 - b1) * t), ) class Rain: def __init__(self, root): self.canvas = tk.Canvas(root, width=W, height=H, bg=BG, highlightthickness=0) self.canvas.pack() self.cols = W // CELL_W self.rows = H // CELL_H + 1 self.heads = [random.uniform(-self.rows, 0) for _ in range(self.cols)] self.speeds = [random.uniform(4, 12) for _ in range(self.cols)] self.tails = [random.randint(8, 22) for _ in range(self.cols)] self.grid = [[random.choice(CHARSET) for _ in range(self.cols)] for _ in range(self.rows)] self.loop() def loop(self): self.canvas.delete("all") for _ in range(int(self.cols * self.rows * 0.02)): self.grid[random.randrange(self.rows)][random.randrange(self.cols)] = \ random.choice(CHARSET) for i in range(self.cols): self.heads[i] += self.speeds[i] * DELAY / 1000.0 end = int(self.heads[i]) for r in range(max(0, end - self.tails[i]), min(self.rows, end + 1)): depth = end - r if depth == 0: color = COLOR_HEAD else: t = max(0.0, 1.0 - depth / self.tails[i]) color = blend(COLOR_TAIL, COLOR_BODY, t) self.canvas.create_text( i * CELL_W, r * CELL_H, text=self.grid[r][i], fill=color, font=FONT, anchor="nw", ) if end - self.tails[i] > self.rows: self.heads[i] = random.uniform(-self.tails[i], 0) self.speeds[i] = random.uniform(4, 12) self.tails[i] = random.randint(8, 22) self.canvas.after(DELAY, self.loop) if __name__ == "__main__": root = tk.Tk() root.title("Code Rain") root.resizable(False, False) Rain(root) root.mainloop()

5.3 tkinter 版绕不开的三个取舍

第一个取舍是帧率。DELAY 设 30 的话画面明显卡，设 80 又显得拖沓，50 是我试出来比较舒服的值。如果你只想要个能跑的效果，别纠结，就用 50。

第二个取舍是颜色计算开销。blend()每调用一次都要做字符串切片和格式化，一帧上万次调用也是负担。优化办法是把亮度也做缓存——建一个{(char, level): color_string}的字典，跟 pygame 版一个思路。这个改动不大，但能再挤出一截性能。

第三个取舍是字体。tkinter 直接用系统字体名，("Consolas", 14)在 Windows 上有，macOS 上会回退到别的字体。稳妥点写("Courier New", 14)，三个平台基本都有，虽然字形没那么好看。真在意的话，可以用tkinter.font.families()查一下系统里有哪些等宽字体再选。

6. 性能实测与优化路径

6.1 从 90% CPU 到 15%，改了哪三处

我把优化前后的数据记了一下，环境是一台四年前的轻薄本、1080p、字号 18、满屏约 2400 个可见字符：

第一处的收益最大，占了七成以上。这里要特别说一句“加帧率上限”的收益：不加clock.tick(FPS)的话，死循环会以屏幕刷新率疯狂跑，本来 60 帧够用，它非要跑到 300 帧，白白烧 CPU。加个上限，画面观感一模一样，风扇立刻安静。

第二处的收益容易被忽略：减少可见字符数比优化绘制更有效。字号从 18 调到 22，字符数少了三分之一，画面反而更霸气，因为字大了。如果你在低配机器上跑，第一件事就是调大字号。

6.2 高 DPI 屏幕上的模糊问题

在 Windows 高分屏或 macOS 的 Retina 屏上，pygame 窗口可能被系统按比例缩放，结果就是画面发虚，字符边缘糊。这不是代码写错了，是操作系统的 DPI 缩放机制。

处理办法有两个。一是启动时告诉系统“这个程序我自己管 DPI”，在pygame.init()之前加：

import os os.environ["SDL_WINDOWS_DPI_AWARENESS"] = "permonitorv2"

二是干脆绕过缩放，直接把窗口尺寸设成物理分辨率，再全屏。这个方案更粗暴但更可靠，缺点是你得自己算好字号，保证列数是整数。

6.3 录屏导出：怎么录才不掉帧

想把它做成 GIF 发出去，直接录屏往往掉帧。我的做法是逐帧导出图片再合成，完全绕开录屏工具的性能干扰：

frame_idx = 0 while running: # ... 正常绘制 ... pygame.image.save(screen, f"frames/{frame_idx:05d}.png") frame_idx += 1 if frame_idx > 600: break clock.tick(FPS)

存够 600 帧（10 秒），再用 ffmpeg 合成：

ffmpeg -framerate 60 -i frames/%05d.png -vf "fps=30,scale=960:-1" -loop 0 out.gif

注意导出时把 FPS 保持在 60 采集，合成时再降到 30，这样 GIF 体积能小一半，观感损失几乎看不出来。另外存帧的时候记得先把frames目录建好，pygame 不会自动创建。

7. 常见问题与排查实录

7.1 问题速查表

7.2 几个我踩过的真实坑

坑一：字符内容每次都重新随机，看起来像故障。我最初的实现里，绘制时直接random.choice(CHARSET)取字符，根本没存二维数组。结果就是每个格子每帧都在变，画面像老电视的雪花。正确的做法是维护一个grid二维数组，每帧只改其中一小部分。这个改动看着不起眼，观感差了一个量级。

坑二：列的回收判断写反了。我一开始写的是if col.head > rows: reset()，只判断头部离开屏幕。结果拖尾还挂在屏幕上呢，这一列就从顶部重新开始了，画面上会出现上下两段雨同时存在，中间断开。正确条件是end - col.tail > rows，整条尾巴都出界才算走完。

坑三：全屏之后所有参数都不对了。我在窗口模式下把参数调到满意，全屏一开，列数从 71 变成 106，雨密得像一堵墙。教训是分辨率变化会直接改变列数和行数，参数必须跟着重新校准。如果要做成能切分辨率的程序，把速度单位从“行/秒”换算成“屏幕高度比例/秒”会更稳。

坑四：pygame 装好了但 import 报错。十有八九是装到了另一个 Python 环境里。用python -m pip install pygame而不是直接pip install，能保证装到当前解释器下面，这个习惯值得养成。

提示：调试视觉参数时，别反复启动程序。在循环里加一句键盘响应，比如按上下箭头实时加减MUTATE_RATE，按左右箭头加减速度范围，几秒钟就能试出最优组合，比改代码重启快十倍。

8. 还能玩出什么花样

原版效果做稳定之后，我陆续加了几个变体，都只需要在现有代码上改十几行，这里把思路留给你。

彩色版本：把BODY_COLOR用 HSV 空间生成，每列给一个随机的色调偏移，画面会变成青紫、橙红的混合雨，科技感更足。改动点就在GlyphCache里，把_mix的终点色从固定值改成按列传参。缺点是缓存键要多带一个维度，内存翻几倍，但依然可接受。

交互版本：加个鼠标位置检测，靠近鼠标的区域让拖尾变亮或速度变快，像是被搅动了。实现上是在绘制前判断一下格子中心和鼠标的距离，做个亮度加成。

扫描线叠加：在最后一层盖一张横向条纹的透明图，模拟老显示器的扫描线，复古味立刻就出来了。生成这张图不需要素材，几十行循环往一个Surface上填一行黑一行透明即可。

字符集替换：把CHARSET换成你熟悉的符号集，比如二进制只有 0 和 1，或者换成偏旁部首、希腊字母、几何图形，气质完全不同。我甚至试过换成 emoji 之外的表情符号，效果意外地有意思，不过这类字符宽度不一致会破坏网格，得慎重。

最后分享一个我在调这类视觉效果时反复验证的经验：先让画面稳定在 60 帧，再谈好不好看。掉帧的动画再炫也留不住人，而参数调优的空间永远是有的。我通常的做法是先把所有"会变化"的东西做成变量顶在文件头上，跑起来之后开着窗口一边看一边改数值，改到满意再收工。这套流程走下来，一个晚上足够把效果调到能直接发出去的水平。