写 Python 的人也分两种一种是把代码跑通就算完事另一种是跑通之后会忍不住盯着终端里那几秒的转圈时间心里琢磨着这事儿还有没有救。我属于后者。说实话Python 的性能问题从来不是一个“非黑即白”的话题——它确实比 C 慢但你遇到的 90% 的性能问题跟 Python 本身没有多大关系而是出在数据结构选型、算法复杂度、无效 I/O 和没必要的复制上。这篇文章我想跟你聊一聊我在真实项目中用过的、踩过坑之后沉淀下来的性能优化思路。不是背书全是实操。无论你是在做数据分析、写后端服务、搞爬虫还是写自动化脚本只要你希望自己的代码跑得更快、更省内存这篇都值得你花十分钟看完。1. 性能剖析先行不知道慢在哪就别动手改我在很多地方强调过同一个观点性能优化第一步永远不是凭感觉改代码而是先找出真正的性能瓶颈。凭直觉猜热点十次有八次是猜错的。Flask 接口慢了你盯着视图函数看了半天最后发现慢的是模板渲染数据处理脚本卡住了你以为是无序字典慢实际上慢的是在循环里不断拼接字符串。这种情况我见得太多了。1.1 cProfile给代码做一次全身体检Python 标准库里的cProfile是我第一个会用的性能剖析工具。它不需要安装任何第三方依赖直接命令行就能跑python -m cProfile -s cumulative your_script.py-s cumulative是让输出结果按累计耗时排序。这个操作会把每个函数的调用次数、耗时都列出来效果相当于给代码做了一次全身 CT。跑完之后你会看到一张表里面有ncalls调用次数、tottime函数自身运行时间不含子调用、cumtime函数总耗时包含所有子调用。重点盯tottime比较大的函数——那才是真正供着时间的大爷。举个例子之前帮某开发者排查一个慢得像乌龟的数据清洗脚本用cProfile一跑发现日志解析函数本身只占了 10% 的时间而里面反复调用的一个字符串处理函数占了近 60%。问题一目了然根本不用猜。如果你不想在命令行里看那张大表也可以把剖析结果导出后用可视化工具观察import cProfile, pstats from io import StringIO prof cProfile.Profile() prof.enable() # ... 这里放你要剖析的代码 ... prof.disable() s StringIO() ps pstats.Stats(prof, streams).sort_stats(cumulative) ps.print_stats() print(s.getvalue())注意cProfile本身会对程序引入一定的开销跑出来的绝对时间不是真实线上运行时间。你关注的是相对耗时分布而不是具体毫秒数。1.2 timeit单点函数的精确计时cProfile适合看全局热点但如果你想对比两个写法的性能差异比如“用推导式还是用循环”那就得用timeit。这个模块的强项在于它会把代码重复执行多次尽量减少系统其他进程的干扰最终给你一个相对稳定的结果。在命令行里用的方式很简单python -m timeit -n 1000000 -r 5 sum(range(1000))-n指定执行次数-r指定重复轮数。代码里也可以用import timeit t1 timeit.timeit(lst [i**2 for i in range(1000)], number100000) t2 timeit.timeit(lst []\nfor i in range(1000):\n lst.append(i**2), number100000) print(f推导式耗时: {t1:.3f}s) print(f循环耗时: {t2:.3f}s)实测下来推导式通常会有 20%~30% 的性能提升数据量越大这个差距越明显。用timeit做这种微观对比是验证“哪种写法更快”的最靠谱方式。1.3 py-spy线上服务的性能采样神器cProfile有一个硬伤修改代码才能用。线上服务你总不能随便重启吧这时候就轮到py-spy上场了这是一个可以附加到正在运行的 Python 进程上的采样剖析工具不需要改代码、不需要重启也不影响服务本身的行为。pip install py-spy py-spy top --pid 进程ID py-spy dump --pid 进程IDtop命令可以直接看到进程内各函数的 CPU 占用的实时排行相当于给运行中的 Python 程序做心电图。这个工具在我排查线上接口 P99 延迟的时候帮过大忙当时用py-spy dump抓了一把堆栈发现所有线程都卡在一个 Redis 批量读取的循环里一层层往上查最终定位到是我用错了客户端 API导致每条数据都走了一次 RTT。2. 数据结构选型性价比最高的优化手段我常说一句话Python 性能优化的第一要义不是优化代码而是选择合适的数据结构。这句话怎么强调都不过分。同样的逻辑用列表实现和用集合实现运行时间可能是两种完全不同的量级。这是很多 Python 初学者最容易忽视的地方也是性能差异最大、改动成本最低的一环。2.1 列表与元组不可变带来的性能红利先做一个简单的比较创建列表和元组的速度。你可能会觉得二者差不多但实测下来你会发现元组创建通常比列表快 5%-10%遍历也更快。原因是元组的结构更简单它在内存里是固定的一块区域而列表因为可变需要预留额外的空间并且维护的信息更多。这不仅仅是“快一点”的差别更关系到代码安全性。如果你有一段数据在逻辑上不应该被修改那就用元组。这既能让意图表达更清晰又能在高频创建的场景下省下可观的资源。比如你在循环里创建几百万个坐标对用(x, y)肯定比[x, y]更省。还有一个列表相关的性能点尽可能预先分配列表容量避免频繁扩容。Python 列表的扩容策略是超量分配但每次触发扩容它都得申请新内存、搬迁旧元素。如果你的列表长度在写代码时就知道就提前用[None] * size固定长度。2.2 集合与字典哈希查找的降维打击列表查找的时间复杂度是 O(n)集合和字典查找的时间复杂度是 O(1)。这意味着什么假设你有一个包含 10 万个元素的列表用if x in lst查找最坏情况需要遍历整个列表而如果换成集合只需要算一次哈希就能定位。数据规模越大这个差距越是“降维打击”。找重复元素、去重、判断是否出现在某个集合中——这些场景一律用集合# 慢的做法列表查找 O(m*n) duplicates [x for x in data if x in existing_list] # 快的做法集合查找 O(mn) existing_set set(existing_list) duplicates [x for x in data if x in existing_set]字典同理。它本质上是一个带值的哈希集合。当你需要通过某个键去频繁查找对应值时字典是最优解。但要注意字典的键尽量用不可变类型比如字符串、元组。如果你用了自定义对象作为键一定要确保它的哈希方法效率够高否则哈希碰撞和复杂哈希计算会让你损失性能优势。2.3 deque 与堆队列和优先级操作的正确姿势用列表的pop(0)和insert(0, x)操作队列是把列表当成了数组用每次都会引起所有后续元素的迁移时间复杂度是 O(n)。如果数据量一上来这种操作会直接把你的程序拖垮。正确的操作是使用collections.deque它是双向队列的实现前后端弹出和插入的时间复杂度都是 O(1)。实测一个 10 万长度的队列用list.pop(0)弹出全部元素的时间约为deque.popleft()的几十倍以上这个差距是可怕的。如果需要“始终能快速拿到最小值/最大值”就要考虑heapq模块。它是 Python 标准库里的堆实现heappush和heappop都是 O(log n) 的复杂度。这个模式在实现定时器任务、优先级队列、Top-K 问题时非常常见正确使用heapq可以避免每次全量排序带来的 O(n log n) 耗时。2.4 一个小节汇总常见结构操作性能对照操作数据结构平均时间复杂度推荐场景按索引访问listO(1)随机访问频繁按值查找listO(n)数据量小按值查找set / dictO(1)数据量大、判重频繁头部插入/删除listO(n)不建议头部插入/删除dequeO(1)队列、双端操作求最小/最大heapheapqO(log n)优先级队列这张表我建议你反复看选错数据结构往往是性能问题的根源而且选错之后怎么调代码都收效甚微。3. 代码细节里的“隐形减速带”数据结构选对了代码也会跑。但同样的业务逻辑不同的写法人能跑出三倍以上的性能差。这一节聊的都是微观层面的优化看起来不起眼但架不住它们是在高频循环里执行积少成多。3.1 局部变量优先作用域查找的代价Python 解析变量的顺序是局部作用域 → 闭包外层 → 全局作用域 → 内置作用域。每多跑一层解析成本就高一点。在高频循环里把全局变量变成局部变量是成本最低但实际效果明显的一个优化。最典型的例子是range、len这些内置函数。在循环里每次调用len(data)都会做一次内置名字查找如果你把它提前赋值给局部变量速度会微涨# 慢速版本 for i in range(len(data)): process(data[i]) # 提速版本 n len(data) for i in range(n): process(data[i])你甚至可以把循环体里频繁调用的函数绑定成局部变量process_func process for item in data: process_func(item)这个技巧本身改变的是字节码指令——局部变量用的是LOAD_FAST比LOAD_GLOBAL要快不少。很多追求极致性能的第三方库内部大量使用这个技巧。3.2 内置函数和标准库现成轮子就是快Python 的内置函数大多数是 C 实现的比如sum、max、min、map、filter。在纯 Python 里写循环执行同样的逻辑就算代码再简洁也跑不过 C 层面的内建函数。举个我印象深刻的例子求一个包含 100 万个数的列表的和。写循环逐个累加跟直接sum(lst)后者快了一个数量级。就是因为sum内部用 C 循环完成累加循环开销在 C 层而不是 Python 解释器。字符串处理时正则表达式用了 C 加速文件读取时readlines和迭代器各有优势。你能找到合适的标准库函数就不要自己去造轮子。单纯的“会用 Python 语法”和“会用 Python 的标准库”写出来的程序性能不是一回事。3.3 列表推导式与生成器表达式写法与性能的双赢列表推导式之所以比for循环快是因为它在字节码层面做了优化减少了循环内的append属性查找和函数调用开销。这是我实测验证过很多次的结论不只是在测试环境在真实的日志处理项目中也有体现。squares [i * i for i in range(10000)]比这个写法快 20% 以上squares [] for i in range(10000): squares.append(i * i)但要注意如果range(10000)换成了一次 I/O 操作或者复杂计算那性能提升会被分摊。推导式的核心价值在于“无副作用的纯计算”。生成器表达式则是另一个维度——省内存。它不会一次性生成完整列表而是逐个产出。你处理几百万条日志时用生成器表达式可以保持内存占用基本恒定这是列表推导式做不到的。3.4 字符串拼接join 才是正解字符串在 Python 里是不可变对象这也就意味着每次用拼接字符串都会分配一块新的内存然后复制旧值和新值。在循环里频繁做这件事就是 O(n²) 的时间复杂度数据量一大立刻崩溃。我见过最惨烈的案例一份查询结果有 5 万条记录用循环拼成一个大字符串跑了一分多钟没出结果。换成.join(list)之后一秒内完成。性能差距超过一个数量级。# 慢速版本 result for item in items: result str(item) , # 快速版本 result ,.join(str(item) for item in items)如果拼接的是少量元素用 f-string 或format都没问题。只有大量拼接时join才是那个正确的选择。注意join里传入的生成器表达式其实还是内部套了一层生成器但如果你的数据本身就在列表里直接用列表传给join是最快的。4. 缓存与惰性求值用空间换时间是高性价比投资很多性能问题本质是“重复计算”——同一个结果被反复运算了成百上千次。优化这类问题最直接的手段就是把它缓存下来需要时直接取不需要时就算都不算。Python 为我们提供了非常优雅的缓存原语。4.1 functools.lru_cache一行代码的缓存魔法functools.lru_cache是个装饰器带上它之后函数会被自动加上缓存能力相同参数的调用结果会直接从内存返回不再重新计算。这个工具用在递归、耗时的纯函数上面效果惊为天人。之前我写了一个经典的斐波那契递归在参数到 35 时就已经卡得不行加上lru_cache(maxsize128)之后参数加到 1000 都能瞬间返回。当然这不是让你用递归算斐波那契而是说明缓存解决重复子问题的能力有多强。from functools import lru_cache lru_cache(maxsize256) def expensive_function(x): # 假设这里做了大量计算 return resultmaxsize参数控制最多缓存多少个结果达到上限后新的调用会挤掉最久没被使用的缓存项就是 LRU最近最少使用策略。如果你确定参数范围有限、结果都能缓存可以用cachePython 3.9它是不设上限的lru_cache的简化版。但有一个重要的坑被lru_cache装饰的函数参数必须是可哈希的。如果你传了一个列表或者字典进去运行时会直接报错。遇到这种情况要么把参数转换成元组再传入要么干脆别用缓存装饰器。4.2 手动缓存与全局变量注意事项有时候缓存逻辑比较复杂比如根据多个字段组合判断、需要考虑缓存过期时间这时候lru_cache就不够灵活了。你可以自己实现一把字典缓存搭配全局或闭包变量使用。我在实际项目中就干过这个事跨接口请求的令牌是临时有效的我在模块里放了一个_token_cache字典记录令牌和过期时间戳。每次调用接口前先查缓存过期才去重新获取。这样一来同样的请求在有效期内能被反复复用接口整体耗时降了一半以上。顺带说一句如果你在代码里大量使用了全局缓存变量务必配合前面第 3.1 节提到的局部变量优先原则。高频访问缓存的时候先把缓存字典赋值给局部变量再访问性能还能再上扬一点点。4.3 生成器与惰性求值不着急算的先欠着缓存是“算一次存起来”惰性求值则是“能不算就不算”。生成器和yield就是实现惰性的原生工具。函数里遇到yield后不会立刻执行完所有逻辑而是每次调用方请求时才推进一步。这个模式非常适合处理超大数据集。我之前写过一个日志分析工具要读取几个 GB 的日志文件用read()一次性读入内存早就挂了。用生成器逐行读取def read_large_file(file_path): with open(file_path) as f: for line in f: yield line.strip() for line in read_large_file(huge.log): process(line)这里逐行读取本身也是文件对象的惰性行为——文件对象是一个迭代器它会自己管理缓冲不必我们手动处理。生成器的价值在于它让“处理完一行就丢弃一行”内存占用与实际文件大小无关。从函数式编程的角度生成器表达式也是惰性的。需要把所有结果拿出来时才真正计算。用好了它内存不再是瓶颈。5. 并发与并行把闲置的 CPU 和等待时间抢回来有些性能问题出在“代码本身跑得慢”另一些则出在“有大量时间在等待”。比如网络请求、文件 I/O、数据库操作这些任务实际上大部分时间都在等对方的响应。这时候单纯优化 CPU 计算逻辑是没有用的必须把等待时间利用起来。5.1 GIL 与多线程的真相Python 的多线程长期被 GIL全局解释器锁卡住脖子。GIL 保证同一时刻只有一个线程在执行 Python 字节码所以多线程对 CPU 密集型任务基本没用但对 I/O 密集型任务情况则不同。因为 I/O 等待时会释放 GIL其他线程就可以继续跑自己的逻辑多线程在这种场景下依然能带来显著提升。我之前给某公司写过一个并发请求工具用线程池去请求几十个接口每个请求 1 秒串行 40 秒线程池 8 个线程跑完只要 5 秒左右。这个提升是非常可观的值得每一位写爬虫、写调度脚本的人掌握。5.2 CPU 密集型任务multiprocessing 才是正解如果你的任务主要在算数、处理大数组、遍历大数据集那就要考虑多进程。multiprocessing模块可以绕开 GIL因为每个进程都有独立的 Python 解释器和内存空间。使用进程池是最简单的接入方式from multiprocessing import Pool def process_one(item): return item * 2 if __name__ __main__: data list(range(100000)) with Pool(4) as p: results p.map(process_one, data)Pool会根据 CPU 核数为你分配进程map会把任务分发下去再汇总结果。这里要特别注意多进程之间内存不共享。你传给子进程的数据会被序列化复制一份如果数据量特别大序列化和传输的开销会抵消计算加速带来的收益。这种情况下你可能要考虑共享内存机制或者干脆用multiprocessing.Manager来管理共享对象但这毕竟是复杂场景能不碰先不碰。多进程适合“CPU 密集 任务可拆分 单份数据体积可控”的场景比如批量处理图片、计算量大的数据分析任务。用好了它是神器用不好就是内存爆炸的元凶。5.3 I/O 密集型任务asyncio 的优雅异步asyncio是 Python 3.4 引入的异步 I/O 框架它采用事件循环加协程的方式在单线程内实现了海量并发。协程的切换成本比线程还低可以同时管理成千上万个 I/O 任务。一个典型的异步 HTTP 请求池import asyncio import aiohttp async def fetch(session, url): async with session.get(url) as resp: return await resp.text() async def main(): async with aiohttp.ClientSession() as session: tasks [fetch(session, url) for url in urls] results await asyncio.gather(*tasks) asyncio.run(main())gather会并发调度所有协程是异步编程里“并发拉满”的核心 API。相对于线程池asyncio 的协程在内存开销上更小启动上万个任务毫无压力而线城的话线程切换成本就非常高了。但要提醒一点asyncio 并非万能如果你手里的库没有异步版本比如大多数传统数据库驱动那在事件循环里执行它们会阻塞整个循环效果比同步还差。这种时候多线程反而更合适。5.4 方案选择一张表讲清楚任务类型推荐方案核心工具CPU 密集计算、遍历大数组多进程multiprocessing / concurrent.futures.ProcessPoolExecutorI/O 密集网络、文件、数据库等待异步/多线程asyncio / ThreadPoolExecutor混合型少量计算 大量 I/O异步为主计算部分另开进程asyncio 进程池海量可拆分的 CPU 任务多进程 分块multiprocessing.Pool选错并发模型往往是灾难性的。一个运行良好的异步程序被不懂的人硬改成多线程后性能不升反降。我见过有人把一个纯 I/O 密集的服务改成 64 线程并发结果 Python 线程上下文切换开销比原本的 I/O 等待还重。方案选型之前先搞清楚你的瓶颈到底是 CPU 还是 I/O。6. 高性能扩展库从 Numpy 到 Numba该不该引入外部依赖当你已经优化了数据结构、代码细节、并发模型之后如果性能依然不满足预期那就得考虑“时间去哪了”大部分瓶颈是在 Python 解释器本身。这时候引入高性能扩展库是突破极限的有效手段。6.1 Numpy向量化思维解放双手Numpy 是我接触到的第一个能让我感觉“Python 也能这么快”的库。它的核心优势是底层的数组操作由 C 实现并且针对连续内存块做了大量优化。用 Numpy 做数组运算相当于把循环从 Python 层挪到了 C 层速度提升通常是几十倍起步。来看一个真实场景。一段逐元素处理的循环for i in range(len(a)): c[i] a[i] * b[i] 1换成 Numpy 一行c a * b 1速度提升在数据量大的时候非常可观。Numpy 的秘诀在于向量化思维——它能对整块数组同时做操作而不是逐元素循环。过去需要写循环的逻辑只要部门可以实现成数组运算就一定能大幅加速。注意Numpy 的向量化操作不适用于所有逻辑。如果每个元素的处理分支逻辑非常复杂、完全取决于上一个元素的结果那向量化就很难展开。这种时候可以考虑用一个支持向量化的辅助数组配合np.where分情形处理。6.2 NumbaJIT 编译给纯 Python 插上翅膀Numba 是另一个让我眼前一亮的神器。它通过 LLVM 把 Python 子集即时编译成机器码实现了接近 C 语言的计算性能。from numba import jit jit(nopythonTrue) def compute_heavy(arr): total 0 for x in arr: total x ** 2 return total加了jit之后这个函数第一次调用时会经历一次编译过程后续调用就直接跑编译后的机器码。实测纯 Python 循环做 100 万次平方累加要几秒用 Numba 之后压缩到了几十毫秒级别。但 Numba 也有使用门槛它不支持全部的 Python 语法不支持动态类型、复杂对象等特性。在处理数值计算、数组运算、循环内简单代数运算时它是最强帮手但如果你在函数里用了一大堆字符串操作、字典嵌套、异常抓取Numba 很可能就编译失败了。用之前请仔细阅读官方的支持范围。6.3 Cython渐进式加速的稳妥之选Cython 属于“编译型 Python”它对 Python 语法做了超集扩展可以让你像写 C 一样声明变量类型然后编译成二进制扩展模块。跟 Numba 相比Cython 的学习曲线陡一些但它胜在支持的范围更广——你几乎可以把任意的 Python 代码改造成 Cython 代码按需加入类型标注。对于实在需要加速、且逻辑不能用 Numpy 向量化也不满足 Numba 条件的核心模块Cython 是一个长期稳定的选择。实际效果上给循环变量加上静态类型声明性能提升通常是几十倍。但引入 Cython 意味着你的项目不再是纯 Python需要一套编译链。对于开源项目或者需要跨平台分发的工具这一步会引入额外的维护成本。如果不是核心路径我不会轻易引入 Cython。6.4 高性能工具选型别让优化本身成为负担我的建议顺序是先用纯 Python 手段优化数据结构、代码细节、缓存、并发实在不行再上 Numpy再不行用 NumbaCython 作为最后的兜底方案。越靠后的手段它的实现成本和维护成本越高。在某些极端情况下引入这些库本身的编译错误、环境依赖问题可能比原先的性能问题还让人头疼。比如在一个没有安装编译器的 Linux 服务器上你没法装 Cython 或者需要预编译的 Numba。这时候用纯 Python 优化到极致反而更现实。7. 一次完整优化案例复盘从剖析到重构理论聊了一大堆还是用我手头一个真实的项目串一遍让你看看这些技巧是怎么组合起来的。之前处理过一个用户行为日志解析工具输入是大约 500 万行日志文本每行包含时间戳、用户 ID、访问路径、停留时间等字段。初始版本跑一次大概需要 8 分多钟说实话能跑但每次改规则都要重构一遍开发体验糟糕透了。我用了渐进式优化的三板斧第一步先用cProfile剖析。结果让我非常意外耗时最高的不是日志解析循环而是一个字段分割时反复调用的自定义函数它内部做了一次正则匹配和两次字符串切片。仅仅这个函数就占了 45% 的总时间。这个发现直接决定了后面优化的大方向——如果可以不用正则就不用了。第二步把自定义函数里的正则替换成字符串split与切片组合配合一点防御性判断。结果总耗时从 8 分钟降到了 4 分钟左右。这个优化本身不复杂但因为没有剖析你可能根本不知道正则表达式是头号嫌疑人。第三步把存储中间结果的数据结构从列表改成字典。原来的代码里每条记录用列表装着处理时按索引去查找字段每次还要确认索引是否存在。改成字典后字段名直接作为键代码可读性提升查找性能也更好。这一步又省了大约 20% 的时间。第四步引入进程池把 500 万行按行拆分成 4 份并行处理。由于每行处理完全独立不存在共享状态多进程并行非常简单。耗时就压缩到了 1 分钟以内。整个过程没有用到任何高深的魔法就是剖析问题、优化热点、选择合理的数据结构、上并发。但最终效果是实实在在的 8 倍以上提升。8. 写在最后优化不是炫技是理解和克制最后一节不聊具体的代码了聊点经验。优化这件事很多人容易上头。我见过有人为了省一点内存用一堆晦涩的生成器和魔法操作把代码写得谁都看不懂也见过有人为了追求纯 Python 的优雅拒绝引入任何库结果代码跑得像拖拉机。我的个人体会是性能优化不是在显微镜下抠每一毫秒而是先找到那个最影响整体耗时的瓶颈用最少的成本解决最主要的问题。代码首先是给人看的其次才是给机器跑的。如果一个优化方案让代码复杂到难以维护除非它是生死攸关的核心路径否则我建议你三思。另外任何优化都要用数据说话。改完代码之后一定要用同一份测试数据对比优化前后的耗时和内存占用确保你的改动真的有效而不是自嗨。timeit、cProfile、memory_profiler这些工具是我每次优化后必用的度量尺。最后分享一个我踩过好多次的坑你在小红书、博客、论坛上看到的性能优化技巧不能盲信。Python 版本不同、运行环境不同、数据规模不同同一段代码的快慢结论可能完全不成立。最好的做法是把这些技巧当作工具箱里的备选方案每次都用timeit亲自验证一次。性能优化本质上是一件用证据说话的技术活。希望这些经验能帮你写出真正飞起来的 Python。