企业官网建设流程全解析

今天想聊一个几乎所有写 Python 的人都会碰到的话题——Python 性能优化。网上关于“Python 跑得慢”的段子一抓一大把，但真正做开发的都知道，大部分程序“卡成 PPT”并不是语言的问题，而是写法、数据结构和方案选型出了问题。我见过不少线上服务，明明 CPU 占用不高，接口却老是超时；也有同事写的脚本要跑一晚上才能出结果，优化之后十几分钟搞定。问题不在别处，就在代码本身。

这篇文章我会沿着一条完整的优化路径走一遍:怎么用工具定位瓶颈、怎么从算法和数据结构上拿到最大增量、怎么写更快的代码细节、怎么用多进程和异步突破单核限制，最后用 Numba 把纯 Python 循环压到接近 C 的速度。每一节都会有可直接抄的代码和参数，适合所有写过一段时间 Python、开始对性能有要求的读者，不管是写脚本、写爬虫、做数据处理还是写 Web 服务，照着思路走基本能让代码上一个台阶。

1. 性能优化不是玄学：先找出瓶颈再动手

我见过太多人一上来就改代码，把 for 循环改成列表推导式，把没用到的库删掉，结果程序还是慢。为什么？因为根本没找准痛点。性能优化的第一原则是：没有测量，一切讨论都是猜。先花十分钟定位热点，往往能省下后面好几天的无效工作。

1.1 用 cProfile 快速定位热点函数

Python 自带的cProfile是性能分析里最趁手的工具，不需要装任何第三方库。用起来很简单：

python -m cProfile -s cumulative your_script.py

它会逐行统计每个函数的调用次数和耗时，-s cumulative表示按累计耗时排序，这样可以一眼看到“谁的总耗时最高”。实际输出里几个关键字段的意思是这样的：

读输出有个小技巧：先把tottime高的函数圈出来，这些是真正在“烧” CPU 的地方；再看cumtime，确认这个热点是怎么被调用链驱动起来的。比如你看到某个parse_line()的 tottime 特别高，再往上翻发现是load_file()反复调它，那优化方向就清楚了。如果直接改load_file()，很可能是白忙活。

用cProfile.run()也可以只分析一段代码，不需要跑整个脚本：

import cProfile cProfile.run("main()", sort="cumulative")

有一点要提醒：cProfile 本质是给每个函数调用挂统计钩子，会显著拖慢程序，尤其对 IO 密集或线程密集的程序，测出来的数据和真实运行会有偏差。这时候可以用py-spy这类采样式 profiler，它不干预程序运行，直接 attach 到进程上采样调用栈，更适合线上环境，以后排查疑难杂症会用得上。

1.2 用 timeit 做微基准测试，别拿秒表骗自己

定位到热点函数之后，改完一个细节到底有没有变快，需要用timeit来验证。它专治“感觉快了一点”——感觉这东西极不可靠，尤其在代码从 0.5 秒变成 0.45 秒的情况下。

import timeit setup = """ import random data = [random.random() for _ in range(100_000)] """ stmt = "sum(data)" result = timeit.timeit(stmt, setup=setup, number=1000) print(result)

number=1000表示把sum(data)连续执行 1000 次，取总时间。我一般会配合repeat参数：

res = timeit.repeat(stmt, setup=setup, number=1000, repeat=5) print(min(res))

为什么取min而不是平均值？因为机器上总会有系统调度、其他进程抢占等干扰，平均值容易被极端噪声带偏，而最小值最接近“代码本身的真实耗时”。正常情况下单次测量应该让程序跑几十毫秒以上，如果太快，就增大number；如果太慢，就减小number。比如一个函数单次只要 0.01 毫秒，number=1000算下来才 10 毫秒，噪声影响就很大，我会调到number=100_000。

还需要注意perf_counter()、process_time()、time.time()这几个时间的区别。perf_counter是墙上时钟（wall clock），包含睡眠等待时间，适合测真实耗时；process_time只统计当前进程消耗的 CPU 时间，不受 sleep 影响。要测一个 IO 密集任务到底“等了多少时间”，用perf_counter；要测一个计算任务“吃了多少 CPU”，用process_time。用错了工具会得出完全相反的结论。

2. 算法与数据结构：性能的主要增量

很多人迷信“微优化”，觉得把循环改快一点、函数少调几次就能逆天改命。实际上，绝大多数性能问题出在算法复杂度上。一个 O(n²) 的算法优化得再漂亮，数据量上来之后照样拖垮机器；换成 O(n log n) 的算法，哪怕写得粗糙一些，跑起来也轻松得多。

2.1 复杂度选型：数据结构决定了你能跑多快

来做一个最经典的对比：在列表里查找一个元素，和在一个集合里查找一个元素。列表in操作的时间复杂度是 O(n)，数据量大了线性扫描很耗时间；集合底层是哈希表，in操作均摊是 O(1)。我用 100 万个整数的列表和集合实测过，列表的100_000 in my_list平均要扫五十万次，而集合几乎瞬间返回。道理很直白：列表像翻抽屉找东西，运气不好要翻遍所有抽屉；集合像有索引的档案柜，根据编号直接翻到那一格。

如果你有一个高频检查“某个 ID 是否存在”的需求，第一反应就应该是集合而不是列表。判断“对象是否重复”也是这样，seen = set()几乎是万能解法。

另外，如果你需要在一个有序列表里反复插入并保持顺序，不要自己写二分查找，直接用bisect模块：

import bisect data = [1, 3, 5, 7, 9] bisect.insort(data, 6) # data -> [1, 3, 5, 6, 7, 9]

bisect.insort的查找部分已经帮你优化好了，底层用 C 实现，比自己写的二分循环快。还有一个细节：字典和集合的键要求可哈希。如果你用自定义对象做键，必须同时实现__hash__和__eq__，而且保证哈希值在对象生命周期内不变；否则会出现“键放进去了却找不到”的诡异问题，排查起来很头大。

2.2 用缓存消灭重复计算：lru_cache 是递归程序的神

很多程序慢，不是因为单次计算贵，而是同一个结果被反复计算。最典型的例子就是递归求斐波那契数列：

def fib(n): if n < 2: return n return fib(n - 1) + fib(n - 2)

不加缓存时，fib(35)就要跑差不多一秒；到fib(40)已经要好几秒，调用次数呈指数爆炸。原因是同一个fib(20)会被重复调用无数次。加一个lru_cache装饰器，问题直接解决：

from functools import lru_cache @lru_cache(maxsize=128) def fib(n): if n < 2: return n return fib(n - 1) + fib(n - 2)

lru_cache会记住每个输入对应的输出，后续调用直接命中缓存。maxsize是能缓存多少个结果，这个参数怎么选？如果函数入参组合有限、内存充足，可以设大一些，命中率更高；如果入参组合非常多，设太大容易让字典占满内存。我通常对递归函数设 128 或 256 就够，对配置解析、价格查询这类低频函数可以设到 1024。注意maxsize=None意味着不淘汰，要谨慎使用，避免无限增长。

缓存思想不只适用于递归。爬虫里重复请求同一个 URL、数据处理里反复读取同一个文件、批量接口调用里反复解析同一段配置，全部可以用缓存解决。工程实践上，缓存的难点不是“用不用”，而是“什么时候失效”。如果数据会更新，记得给缓存加过期时间，或者使用带失效机制的缓存库。

2.3 从 O(n^2) 到 O(n)：一次真实的改写

看一个很常见的场景：在一个数组里找两个数，使它们的和等于目标值。很多人第一反应是双重循环：

def two_sum_naive(nums, target): for i in range(len(nums)): for j in range(i + 1, len(nums)): if nums[i] + nums[j] == target: return [i, j]

这个写法在几万个元素的数组上就会明显变慢。改用哈希表存“已经见过的值”，一次遍历就搞定：

def two_sum(nums, target): seen = {} for i, v in enumerate(nums): if target - v in seen: return [seen[target - v], i] seen[v] = i return []

第二个版本的时间复杂度是 O(n)，空间复杂度也是 O(n)。这是典型的“空间换时间”，用一份字典的代价换掉了整个内层循环。我在优化数据处理脚本时，经常遇到类似的结构：一个循环里套一个查找，把查找换成哈希表，整体耗时立刻下降一个数量级。写代码时只要闻到“循环套循环”的味道，就要警惕是否能用哈希表或集合重写。

当然，空间换时间要有个度。如果一个 n 非常大的场景，额外内存可能也要几百 MB，这时候需要权衡：是继续用 O(n²) 时间换取少量内存，还是加内存换时间。没有银弹，但大多数业务场景里，单机上几百 MB 内存通常比几十秒 CPU 等待更不值得。

3. 代码层级的微观优化：小习惯差一大截

算法和数据结构搞定了，接下来才是抠代码细节。这些优化单个看都是几毫秒、几十微秒的收益，但放在高频调用的热点路径上，积少成多非常可观。这里说的都是常规文档里容易忽略但实际收益明显的点。

3.1 局部变量绑定与内置函数的正确用法

Python 的属性访问（比如math.sqrt里的点号）比局部变量访问慢很多，因为点号背后是字典查找和方法解析。在循环里反复访问同一个属性，等于每次都做一次查找。解决办法很简单：在循环外把它绑定为局部变量。

import math # 不推荐：反复属性查找 for x in data: y = math.sqrt(x) # 推荐：先绑定再循环 sqrt = math.sqrt for x in data: y = sqrt(x)

这个写法不是玄学，实测在循环量大的情况下可以减少不少属性查找开销。同理，len()、内置函数在 Python 3 中已经很快，但如果你在一个超长循环里反复调用某个常用函数，也可以先绑到局部变量上。不过不要走火入魔——只在热点路径里用，普通代码保持可读性更重要。

另外，map、filter这类内置函数返回的是生成器对象，本身不会立即执行计算，只有迭代时才逐项产生结果。这意味着它们天然适合处理大数据流，不会一次性把整个中间列表放进内存。但要注意：如果后续操作必须拿到完整列表，那你最终还是一样要付出列表化成本。判断标准很简单——下游需要逐项处理就用生成器，需要反复随机访问就用列表。

3.2 字符串拼接、列表推导式与生成器的选择

字符串拼接是一个非常经典的性能陷阱。很多人习惯用+=循环拼字符串：

parts = ["a"] * 100_000 s = "" for p in parts: s += p

这个写法的问题在于字符串是不可变对象，每次+=都会创建一个新字符串，把旧内容复制一遍。数据量大了之后，总复制量是 O(n²) 级别的。正确做法是用join：

s = "".join(parts)

join一次遍历所有片段，只需要一次分配。实测同样拼十万个短字符串，join比+=快几十倍。这不是“尽量用”，而是“必须用”。每次看到循环里拼字符串，我都建议立刻改成join或列表收集后一次性拼接。

列表推导式比手动append循环快，这已经是常识了，因为列表推导式底层走的是专门的字节码，不用反复调用append方法。比如：

# 不推荐 result = [] for x in data: if x % 2 == 0: result.append(x * x) # 推荐 result = [x * x for x in data if x % 2 == 0]

但要注意，如果推导式里的表达式非常复杂，甚至要调用一个耗时函数，那收益会被计算本身淹没。还有一点：生成器表达式(x * x for x in data)在内存上比列表推导式节省得多，适合处理海量数据流；但如果你的代码很快就要遍历多遍，就老老实实用列表，生成器只能遍历一次，第二遍就得重建。

3.3 标准库里的“性能加速器”：排序、计数与迭代工具

标准库里藏着不少常被忽略的性能利器。先说排序，sorted(data, key=func)里的key参数非常关键，它会让每个元素只调用一次func算出排序键，而不是在比较时反复调用。如果你需要按对象的某个属性排序，千万别写自定义比较函数，直接用key=lambda x: x.attribute，差距在数据量大时很明显。

再说计数。统计大量元素出现次数，有人喜欢手动维护字典：

counts = {} for x in data: counts[x] = counts.get(x, 0) + 1

这个写法没错，但collections.Counter更简洁：

from collections import Counter counts = Counter(data)

Counter本身是字典的子类，底层和手动计数一样，但代码更清晰。如果数据规模特别大，还可以考虑用counts.update(batch)分批累加。

itertools模块则提供了大量高性能迭代工具：islice做切片不复制列表、chain拼接多个迭代器、groupby做分组处理。我经常用islice避免复制巨大的切片列表。举个例子，对一百万条日志取前一百条：

from itertools import islice first_100 = list(islice(log_lines, 100))

如果不这样写，直接log_lines[:100]，会先把整个列表的切片逻辑跑一遍、分配新列表，虽然结果一样，但无谓开销不小。

要警惕的是，这一层的优化容易上瘾，陷入“为了快而快”的误区。我的原则是：先跑通功能，再用 profiler 找到真实热点，最后只对热点做微观优化。可读性是长期维护成本的一部分，过度使用晦涩写法得不偿失。

4. 并行与异步：突破单核的瓶颈

前面聊的都是单线程内的事，再优化也有物理上限。如果程序仍然慢，就该考虑让多核 CPU “同时干活”了。Python 的并行和异步向来是重灾区，很多人分不清线程、进程和协程的适用场景，一上来就开线程池，结果 CPU 密集任务反而更慢。这一节把机制和选型一次讲清楚。

4.1 先认清 GIL，再决定用线程还是进程

Python 解释器里有一把全局锁，叫 GIL（Global Interpreter Lock），它保证同一时刻只有一个线程能执行 Python 字节码。所以纯 CPU 密集型任务用多线程，不仅不会更快，还会因为线程切换开销变得更慢。真正的多核并行，只能靠多进程实现。

判断任务属于 CPU 密集还是 IO 密集，有个很实用的观察方法：运行程序时看 CPU 占用率和sleep状态。如果任务跑起来 CPU 立刻飙到 100% 以上，大概率是计算密集；如果任务大部分时间在等待网络响应、等待磁盘读取，CPU 占用很低，就是 IO 密集。IO 密集适合线程池或异步，CPU 密集适合进程池。

还有个经常被忽略的点：Python 3.13 开始引入了实验性的自由线程模式（free-threading），可以真正去除 GIL，但目前还属于新特性，生态兼容性需要仔细验证。短期内在生产环境，还得按传统方案选型。

4.2 多进程池与任务切分的正确姿势

用多进程做 CPU 密集任务，最省事的入口是concurrent.futures.ProcessPoolExecutor。示例：

from concurrent.futures import ProcessPoolExecutor def cpu_heavy(n): return sum(i * i for i in range(n)) def main(): with ProcessPoolExecutor(max_workers=4) as executor: results = list(executor.map(cpu_heavy, range(8))) print(results)

关于max_workers怎么选，我一般先看机器核数，os.cpu_count()能拿到逻辑核心数。但不要直接设满，因为主进程本身也要做任务调度和数据收集，系统还要跑其他程序。我通常设max_workers=os.cpu_count() - 1，或者按任务的 CPU 密集程度微调。极端情况下如果每个子进程内存占用很大，还需要同时考虑内存上限。

使用进程池有几个坑要特别留意。

第一个坑是参数传递。进程池传递任务参数时要经过 Pickle 序列化，如果传输的是很大的 DataFrame 或大对象，序列化时间可能比计算本身还长。解决办法是把大对象放到共享内存、文件系统或数据库里，传给子进程的只是文件路径或索引。

第二个坑是异常处理。executor.map返回的结果是惰性生成的，如果某个子任务抛了异常，异常会在迭代到那个任务时才抛出，不会在提交时立刻报错。最好用submit+as_completed加try/except包住future.result()。

from concurrent.futures import ProcessPoolExecutor, as_completed with ProcessPoolExecutor(max_workers=4) as executor: futures = [executor.submit(cpu_heavy, n) for n in range(8)] for fut in as_completed(futures): try: result = fut.result() except Exception as e: print("任务失败:", e)

第三个坑是 Windows 下的模块导入。在 Windows 上，多进程会用spawn方式创建子进程，它需要重新导入主模块。如果主代码直接写在顶层没有if __name__ == "__main__":保护，子进程会在导入时无限递归创建新进程，直接抛 RuntimeError。所以，任何涉及多进程的脚本，主执行逻辑都要包在if __name__ == "__main__":里。这个坑在 Jupyter Notebook 里尤其阴险，直接在 Notebook 里跑ProcessPoolExecutor经常不工作，建议先导出为.py文件再运行。

4.3 异步IO：把等待时间捡回来

IO 密集场景，比如要请求几百个 URL、查几百个数据库，用asyncio效果非常显著。我用一个很直观的例子说明：同步串行请求 200 个网页，假设每个请求 0.3 秒，总耗时 60 秒；用asyncio并发拉起 50 个连接，总耗时可能只有 6 秒。省下来的不是 CPU 时间，而是并发等待的时间。

一个简单的异步请求示例，需要先pip install aiohttp：

import asyncio import aiohttp async def fetch(url, session): async with session.get(url) as response: return response.status async def main(): urls = ["https://example.com"] * 50 async with aiohttp.ClientSession() as session: tasks = [fetch(url, session) for url in urls] results = await asyncio.gather(*tasks) print(results) # asyncio.run(main())

异步代码最关键的禁忌是：在事件循环里调用阻塞函数。比如time.sleep(1)、同步的requests.get()、普通的文件读写，这些阻塞调用会卡住整个事件循环，让所有协程一起等待，并发形同虚设。正确做法是使用异步版本（await asyncio.sleep(1)、aiohttp.request），或者把阻塞调用丢到线程池里。Python 3.9 之后提供了非常方便的asyncio.to_thread()：

import asyncio async def main(): result = await asyncio.to_thread(sync_blocking_function, arg1)

asyncio.to_thread会把阻塞任务放到默认线程池执行，不阻塞事件循环。这个函数我从 3.9 开始就在用，迁老代码时非常顺手。另外注意asyncio.gather多个任务时，如果其中一个异常，默认会立刻抛出并取消其余任务。想容错可以给 gather 加return_exceptions=True，逐个检查返回结果——这段经验是从线上报警里学来的：一个请求失败别让整批请求陪葬。

5. 让代码飞起来的终极武器：C扩展与运行时

如果算法、数据结构、并行异步都优化完了，还是有某个纯计算热点绕不开，那就该考虑把热循环交给“编译型”的方案了。这不是让你立刻去学 C，而是有现成的工具可以用，最推荐的是 Numba。

5.1 Numba：一条装饰器获得编译级加速

Numba 是一个 LLVM 编译器，它能把被装饰的 Python 函数即时编译成机器码。用法出乎意料地简单：加一个@njit装饰器。注意要装一下：pip install numba。我用蒙特卡洛模拟求圆周率来演示加速效果，这个例子计算量大、逻辑简单，最适合看对比。

import numba import numpy as np @numba.njit def monte_carlo_pi(n): hits = 0 for _ in range(n): x = np.random.random() y = np.random.random() if x * x + y * y <= 1.0: hits += 1 return 4.0 * hits / n

同样是n = 100_000_000，纯 Python 版本可能要四十秒，加了@njit之后基本一两秒内出结果，加速比往往超过二十倍。为什么这么快？因为@njit默认走nopython=True路径，整个函数从 Python 对象循环变成原生机器码循环，不再有解释器的动态类型开销。它专治“数值计算 + 循环”这种组合。

有几个使用要点必须强调清楚。

第一，第一次调用会比较慢，因为 JIT 要编译。编译耗时通常零点几秒到几秒，看函数复杂度。解决方法是@njit(cache=True)，把编译结果缓存到磁盘，下次启动直接加载，省掉重复编译时间。

第二，@njit不是所有 Python 语法都支持。它支持的是数值运算、NumPy 函数和基本控制流，但动态类型、复杂闭包、某些字符串操作不支持。遇到不支持的代码，Numba 会报错并告诉你是哪一段不适合；这时候别硬掰，把它挪出@njit函数，或者重构成支持的形式。实测下来，凡是不支持的，往往本身也不适合做热循环。

第三，不要在@njit函数里调用不受支持的 Python 对象方法。比如list.append某些情况能支持，但自定义类的属性和方法一般不支持。我一般只把纯计算部分丢进@njit，IO 和业务逻辑留在外面，层层传数据进去。

5.2 Cython与PyPy：什么阶段才值得上

Numba 解决的是“数值计算循环”，如果热点是复杂的业务逻辑、字符串处理、或者需要深度控制内存布局，那就要考虑 Cython 或 PyPy。

Cython 的玩法是写一个.pyx文件，在变量和函数上标注 C 类型，然后编译成扩展模块。它能做到和手写 C 相当的性能，但代价是引入了新的构建流程和类型标注，维护成本明显上升。我的建议是：只有当你已经把算法、数据结构、并行、Numba 都试过一遍，并且瓶颈确实在 Python 对象操作本身时，才值得上 Cython。很多团队项目生命周期里根本走不到这一步，硬上 Cython 往往带来更多坑。

PyPy 是另一个 Python 运行时，自带 JIT，可以不加代码就加速纯 Python 程序。但它对 C 扩展的兼容性是个大问题，很多依赖（比如 pandas、某些科学计算库）在 PyPy 下要么没有预编译包，要么性能反而更差。所以 PyPy 更适合长期运行的、纯 Python 写的数据分析或脚本任务。如果你决定试试 PyPy，先在测试环境完整跑一遍现有测试用例，确认所有依赖都兼容，再谈性能。

选型建议很简单：默认路径是“算法优化 → Numba”；Cython 是为算法库封装而生的，PyPy 是为纯 Python 长跑任务准备的。不要一上来就把所有工具往项目里堆。

5.3 实战案例：文本相似度计算从7秒到0.2秒

这里放一个我实际优化过的小项目案例，可以串起前面所有方法。需求是对 1000 条文本两两计算相似度，输出最相似的前 N 对。初版实现很直接：双重循环 + 自定义编辑距离函数。跑一次要 7.2 秒，看着不算灾难，但如果文本涨到一万条，那就是几百秒，没法接受。

第一步，先跑cProfile，发现热点是两个地方：内层循环里的edit_distance()函数，以及字符串切片操作。瓶颈清楚了。

第二步，算法层优化：编辑距离函数里有大量重复的len计算和二维数组初始化，改用一行数组 + 互相交换的滚动数组写法，把空间从 O(n*m) 降为 O(n)，速度也提升了一截。然后加了一个简单剪枝：如果两段文本长度差超过阈值，直接判定相似度为 0，跳过编辑距离计算。这一步把 7.2 秒压到 2.1 秒。

第三步，把编辑距离函数包上@njit(cache=True)，再做同样 1000 条文本两两对比，耗时直接掉到 0.35 秒左右。四舍五入，整个优化过程相当于把原来跑几十秒级别的批量任务变成了“秒回”状态。

这个案例最有价值的一点是：我没有在一开始就引入 Numba，而是先做算法和剪枝。为什么？因为edit_distance在被@njit处理前，必须先写成支持纯数值运算的形式。先做算法优化，不仅让 Python 版本变快，也让 Numba 的编译更顺畅。顺序反过来的话，你很可能在编译失败、语法不兼容的坑里绕半天，最后还得回头重构。

6. 常见性能问题与排查技巧实录

这一节写点实战中踩过的坑。很多性能和“环境”有关，不是代码本身的锅。

6.1 环境问题：找不到DLL、Python版本带来的性能差异

在 Windows 上运行某些科学计算库，启动时可能直接报“由于找不到 msvcp140.dll，无法继续执行代码”。这通常是因为缺了 Microsoft Visual C++ Redistributable 运行库。这不是代码问题，也不直接算性能问题，但它会让你的程序根本跑不起来，或者一直卡在初始化阶段。解决办法是去微软官网装最新的 Visual C++ Redistributable，装完重启再跑。这个坑我见过很多次，团队新同事在 Windows 上搭环境时几乎每季度都会碰到一次。

另一个容易被忽略的性能差异是 Python 版本。Python 3.11 开始，官方在解释器层面做了大量性能优化，包括新的自适应字节码解释器，常见任务比 Python 3.8 快约 20% 到 60%。我的经验是：如果你还在用 3.8 或更老的版本，迁移到最新的稳定版本身就是一次“免费优化”。当然，升级前要在测试环境完整跑一遍测试用例，重点确认第三方库的兼容性，尤其是科学计算、异步框架这些重依赖。

6.2 profile之后程序反而更慢正常吗

正常，非常正常。cProfile本身有开销，它会记录每个函数的调用次数和耗时，所以打着 profile 的程序会比正常跑慢不少。这不代表程序真的变慢了，只说明测量工具在起作用。真正看的是耗时分布，而不是绝对耗时。如果担心 profile 干扰太大，改用采样式工具如py-spy，它几乎不影响目标进程性能。还有一个无数人踩过的坑：不要在生产环境的入口直接挂cProfile，日志会被输出文件占满磁盘。

6.3 常见性能问题速查表

这张表是我日常排查问题时的“默认菜单”，大部分性能投诉都能对上其中一行。另外还有一个容易忽略的维度是内存，性能瓶颈有时是内存分配太多、GC 频繁触发。可以使用memory_profiler或 tracemalloc 定位内存热点。一个典型场景：循环里频繁创建大列表，导致 GC 频繁执行，CPU 全耗在回收上了。解决方法是用生成器替代中间列表，或者复用已有的对象。

6.4 我把基准测试写进回归测试的一个小经验

最后分享一个我坚持了很久的小习惯：性能优化完成后，把基准测试变成回归测试的一部分。

做法不复杂，比如优化完某个函数后，我会在项目里保留一个benchmark.py，用pytest配合timeit写一条用例，断言这个函数的耗时必须低于某个阈值。阈值留 30% 的余量，避免 CI 环境抖动导致误报。

import timeit def test_hot_function_performance(): stmt = "hot_function(data)" elapsed = timeit.repeat(stmt, setup="from module import hot_function, data", number=10, repeat=3) assert min(elapsed) < 5.0 # 阈值，单位秒

为什么这么做？因为我见过太多“改着改着性能又回去了”的情况。重构、加需求、换依赖，某个不经意的改动可能让之前的优化功亏一篑。基准测试就像一张性能“网”，能在合入代码前就拦住明显的性能回退。说夸张点，性能优化不只是某一次的动作，更应该是一种“代码习惯”。每次写完一段关键代码，顺手跑一句 timeit，记录一份基线；每次改动涉及热点路径时，对比一下数字再合并。这样你的代码库会一直往更快、更稳的方向走，而不是陷入“优化一次、退化半年”的循环。