Python和“慢”这两个词在开发者圈子里几乎总是绑在一起出现。但我得先泼一盆冷水绝大多数你觉得慢的 Python 代码慢的原因根本不是语言本身而是代码写法出了问题。我之前接过一个数据处理脚本跑一次要四十多分钟同事的第一反应是“Python 太慢得换语言重写”。我拿 cProfile 看了一眼几分钟就定位到瓶颈——某个函数里一个 O(n²) 的查找循环占掉了 90% 的时间。把容器换成 set 之后整个任务从四十多分钟压到三分钟。这次经历让我坚定了一个原则先剖析再优化永远比凭感觉重写有效。这篇文章就把我日常工作中反复用到的 Python 性能优化技巧整理成一条完整的实战路线从剖析工具、数据结构选型、循环里的隐形开销到并发与 JIT 加速每一节都能直接照着操作。1. 优化前先问自己性能瓶颈到底在哪每个开发者都会犯同一个错误盯着某一段代码觉得它“看起来慢”然后埋头重写。但多数情况下直觉是错的。你真正要优化的是整个程序里最耗时的那个点也就是所谓的“热点”。找热点的工具我平时主要用三个cProfile做整体剖析line_profiler做行级定位timeit做小片段的微基准。三个工具各有分工组合起来基本能覆盖所有场景。1.1 不要凭感觉优化“这里可能慢”、“那里多了一层循环”、“换个写法应该更快”——这些话我在 code review 里听到过太多次。性能优化的第一原则很简单没有数据支撑的优化全部属于玄学。为什么这么说因为现代 Python 程序的执行路径非常复杂。你以为慢的地方可能早就被解释器优化掉了你觉得没问题的函数却可能在循环里被调用了几十万次。举个很常见的例子很多人看到sorted()就皱眉觉得排序很慢但实际上如果整个程序里它只被调用几次根本不该花时间去优化它。相反某个平平无奇的for循环里藏着一个list.index()那才是真正的性能黑洞。所以动手优化之前先花几分钟跑一次剖析搞清楚时间到底花在哪里。这不仅节约时间还能避免你“优化”完一段无关紧要的代码后自我感动。1.2 cProfile一行命令找出“拖后腿”的函数cProfile 是 Python 标准库自带的剖析器不需要安装任何东西。这是我最先推荐的工具因为它能直接告诉你哪个函数被调用了多少次累计耗时多少。使用方式极其简单python -m cProfile -s cumulative process_data.py-s cumulative表示按累计耗时排序输出这样最耗时的函数会排在最上面。输出结果类似这样583920 function calls (573008 primitive calls) in 3.842 seconds Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 100 0.001 0.000 3.500 0.035 process_data.py:20(process_row) 100 0.002 0.000 3.498 0.035 process_data.py:25(lookup_related)这里有几个关键列需要看懂ncalls函数被调用的次数。tottime函数自身代码的执行时间不含调用的子函数时间。cumtime函数累计耗时包含它调用的所有子函数时间。percall平均每次调用耗时。我一般先盯cumtime因为它能一层一层地剥开调用链。如果某个函数的cumtime特别高就顺着它的调用关系往下钻直到找到tottime也很高的那一层——那才是真正消耗 CPU 的代码。1.3 line_profiler 与 timeit微基准与行级定位cProfile 定位到函数级但函数内哪一行最耗时间它看不出来。这时用 line_profiler 做行级剖析。安装pip install line_profiler在目标函数上加上profile装饰器profile def process_data(): result [] for item in items: if item in lookup_list: result.append(item * 2) return result然后运行kernprof -l -v process_data.py它会输出每一行的执行次数和耗时哪一行是瓶颈一目了然。我见过不少案例疑似“问题代码”的地方耗时很低真正耗时的是旁边一个不起眼的成员检查——这种反直觉的情况只有行级剖析能暴露。timeit 则用来快速验证两个写法谁更快尤其适合对比“用 A 写法还是 B 写法”这类小决策python -m timeit -s data list(range(10000)) result [x * 2 for x in data] python -m timeit -s data list(range(10000)) result list(map(lambda x: x * 2, data))三个工具的适用场景完全不同我在项目里的分工习惯是这样的工具定位层级适用场景输出关注点cProfile函数级整个程序跑一遍找最耗时的调用链cumtime从大到小扫line_profiler行级已经锁定某个函数找具体哪一行慢每一行的% Timetimeit片段级对比两三个写法谁更快单次执行耗时的平均值1.4 一个真实的剖析案例讲个实际例子。之前有个朋友优化他的一段爬虫解析逻辑始终觉得是正则表达式太慢折腾了好久把正则换成字符串切割结果收益微乎其微。后来我帮他用 line_profiler 跑了一遍发现真正耗时的是解析完之后的去重环节——一个两万多个元素的列表每来一条数据就执行一次if item in unique_list。这是典型的 O(n²) 操作元素越多越爆炸。把列表转成set之后整个解析流程直接快了二十多倍。正则根本是背锅的。这个案例我想说明的是绝大多数性能问题都不是“语言慢”而是算法和数据结构选错了。接下来这个章节就专门聊聊容器选型。2. 容器选型决定性能天花板数据结构选型是我做性能优化时最先检查的一环因为它性价比最高不需要改逻辑只需要换一个容器类型收益常常是几十倍甚至几百倍。Python 内建的数据结构看起来都差不多但底层复杂度差别巨大。2.1 查找场景list、set、dict 怎么选这是最常踩的一个坑。很多人习惯把所有数据扔进 list然后反复用in做成员检查。list 的成员检查是O(n)数据量一旦上去循环里每个in都在线性扫描整体复杂度直接变成 O(n²)。而 set 和 dict 的查找是O(1)基于哈希表实现不管容器里有多少元素单次查找的时间基本恒定。一个最典型的改写# 慢一万个元素的列表检查一千个新元素是否存在 items_list list(range(10000)) new_items range(500, 1500) result [x for x in new_items if x in items_list] # 约一千万次比较 # 快先转成 set哈希查找 items_set set(items_list) result [x for x in new_items if x in items_set] # 约一千次哈希查询我实测过这种场景在数据量达到十万级别时set版本比list版本快上百倍。而且注意一点构建 set 本身有一次性开销所以如果只查一两次未必划算但如果是“批量构建、反复查找”的模式set 是无条件更优的。那什么时候用 dict 而不是 set当你不仅需要判断“是否存在”还需要取回对应的值或者需要按维度聚合统计时dict 就是带值的 set。Python 3 之后 dict 的底层实现做了很多优化内存效率和查找速度都相当理想优先使用它完全没问题。2.2 deque别再对 list 做 pop(0)队列场景是另一个高频踩坑点。很多人用 list 模拟队列append()往尾部加没问题但pop(0)从头部弹出这个操作是O(n)的——因为 list 删除头部元素后后面所有元素都要整体前移一位。数据量小的时候看不出来数据量一旦到几万几十万每次pop(0)都要搬移整个数组程序会肉眼可见地卡顿。正确做法是用collections.dequefrom collections import deque queue deque([1, 2, 3]) queue.popleft() # O(1)头部弹出 queue.append(4) # O(1)尾部追加deque 是双端队列头部和尾部操作都是 O(1)。滑动窗口、消息队列、BFS 遍历这类场景它就是标准答案。2.3 lru_cache用空间换时间的正规姿势很多“慢”的本质是同一个计算被反复执行。尤其是纯函数——输入相同、输出必然相同的那种——完全可以用缓存把结果存起来。functools.lru_cache是标准库自带的装饰器用起来非常无脑from functools import lru_cache lru_cache(maxsize128) def get_price(product_id: str) - float: # 模拟一次昂贵的计算或数据库查询 ...经典案例是斐波那契数列的递归实现。不加速的版本计算 fib(40) 大约要跑几秒钟且随着 n 增大呈指数爆炸加上lru_cache之后计算 fib(400) 都是毫秒级因为每个子问题只计算一次。但用缓存之前要想清楚两件事一是内存maxsize设得太大可能把内存吃爆二是数据新鲜度如果底层数据会变化记得用cache_clear()手动清理。还有一种更省内存的方案是用functools.cachePython 3.9它不限制缓存大小适合子问题有限的场景。2.4 大量小对象的内存优化slots如果你的程序需要创建成千上万个自定义对象比如逐行解析日志生成记录对象内存占用往往会超预期。原因是每个 Python 对象默认带一个__dict__字典用来存储实例属性——这个字典本身就要占不少内存。在类中定义__slots__可以告诉解释器这个类的实例只有固定几个属性不需要动态字典class Record: __slots__ (timestamp, value, tag) def __init__(self, timestamp, value, tag): self.timestamp timestamp self.value value self.tag tag代价是无法再给实例动态添加新属性。但对“字段固定的结构化数据”来说内存占用能显著下降访问速度也会微幅提升。我一般只在确认内存是瓶颈、且对象规模很大时使用它日常业务类不会轻易加__slots__毕竟动态属性有时候真的很方便。3. 循环里的隐形开销小习惯决定大性能性能瓶颈十有八九落在循环里。原因很简单循环体内的代码每多一句操作就会被放大成千上万倍。这一节讲的是我几乎每次 code review 都能看见的几种写法问题以及对应的正确姿势。3.1 字符串拼接 看着方便代价很大字符串是不可变对象每次都不是在原有字符串上追加字符而是创建一个全新的字符串再把旧内容和新内容拷贝过去。循环里做s piece执行的其实是 n 次字符串创建整体复杂度O(n²)。# 慢循环里不停拼接 s for word in words: s word # 快一次性 join s .join(words)我在一个实际项目里测过拼接一万个短字符串版本大约需要 80 毫秒join版本只需要 2 毫秒左右。数据量越大差距越夸张。所以只要循环次数可能超过一百字符串拼接就一律用join或列表收集后再合并。3.2 把全局变量和属性访问变成局部变量Python 的变量查找遵循 LEGB 规则局部、闭包、全局、内置。局部变量的查找速度最快全局变量和内置名称的查找要经过额外的字典查找。在循环里反复读取全局变量会白白消耗不少时间。更隐蔽的是属性访问。obj.attr每次都要走一次属性解析如果在循环里反复读取某个对象的同一个属性完全可以把它的值先存到局部变量里。# 慢循环里反复读取全局和属性 def total_len(data): result 0 for item in data: result len(item) # len 是全局查找item 属性访问 return result # 快方法引用先缓存 def total_len(data): result 0 len_ len for item in data: result len_(item) return result这个技巧在微基准里能带来 10% 到 20% 的收益。但要提醒一句这是收益最小、却最容易牺牲可读性的优化。除非已经确认某个热点函数里这里有明显开销否则我不太建议为了这一点收益到处这么写。优化永远先做收益大的再做收益小的。3.3 列表推导式与 map比 for 循环更快的写法在 Python 里for循环配合append()是新手最常见的写法但它确实慢每次迭代都要执行一次属性查找list.append和一次函数调用。列表推导式把这些操作压缩到了 C 层面性能更好代码也更简洁。# 慢 result [] for i in range(10000): result.append(i * 2) # 快 result [i * 2 for i in range(10000)]实测列表推导式通常比 for 循环快 30% 到 50%。map在配合内置函数时有时候更快但可读性差一些而且用不好还得转 list。我的习惯是优先列表推导式只有当推导式变得很复杂时才退回 for 循环保证代码清晰。毕竟可读性是长期维护成本的一部分。3.4 循环内不变量提到循环外还有一种极其常见的浪费循环每次迭代都重新计算一个与循环变量无关的值。比如在循环里重复调用len()获取容器长度或者在循环里反复连接同一个字符串。# 慢n 在循环里被重复调用 for i in range(len(data)): ... total sum(data) for i in range(len(data)): ... # 快先算好 n len(data) for i in range(n): ...这类问题看起来微不足道但一旦循环次数上了百万重复的无关计算也会积累成可观的耗时。优化时养成一个习惯循环体内的代码问自己一句——“这句话真的跟每一次迭代都相关吗”不相关的就提到循环外面去。4. 并发与并行GIL 绕不过去怎么办很多人以为 Python 多线程就能利用多核 CPU结果发现程序不但没加速有时甚至更慢。这背后是 CPython 解释器的一个核心机制——GIL全局解释器锁。4.1 GIL 到底限制了什么简单理解GIL 是 CPython 为了保障内存安全而加的一把锁它确保同一时刻只有一个线程在执行 Python 字节码。也就是说纯计算密集型的多线程程序在单进程内是没法并行利用多核的线程切换的开销反而可能让代码更慢。但 GIL 只锁 Python 字节码的执行。当线程进入 I/O 操作比如网络请求、文件读写、数据库等待时锁会被释放其他线程可以趁机执行。所以I/O 密集型的任务用多线程确实有效这也是很多人“用 threading 优化某个网络请求程序成功”的原因——不是 GIL 失效了而是那些时间花在等待而不是计算上。4.2 CPU 密集任务multiprocessing 与进程池要真正利用多核只能上多进程。每个进程有独立的解释器和内存空间互不干扰。标准库的concurrent.futures.ProcessPoolExecutor是最方便的入口from concurrent.futures import ProcessPoolExecutor def compute_chunk(start, end): total 0 for i in range(start, end): total i * i return total with ProcessPoolExecutor(max_workers8) as pool: chunks [(0, 100_000), (100_000, 200_000), ...] results list(pool.starmap(compute_chunk, chunks))用进程池有几个非常实际的注意点任务的粒度不能太小。进程间通信和结果回传有固定开销如果一个任务只需要几毫秒拆成多进程反而更慢。我一般会量化单个任务至少几秒钟的时候才值得走进程池。传给进程的数据要能 pickle。函数和参数会被序列化到子进程闭包、lambda、某些复杂对象都传不过去。共享内存要谨慎。跨进程改同一个变量不会生效必须用multiprocessing提供的Queue、Value、Array等专门机制。4.3 I/O 密集任务asyncio 是更现代的选择I/O 密集的并发现在的主流方案是asyncio。它用事件循环在单线程里调度多个协程遇到 I/O 等待就切去执行别的任务切换开销比线程还要小。一个简单的示例import asyncio async def fetch_one(url): # 模拟网络请求 await asyncio.sleep(1) return url async def main(): tasks [fetch_one(furl-{i}) for i in range(10)] results await asyncio.gather(*tasks) return results asyncio.run(main())这个程序十个任务各睡一秒总耗时只有一秒左右因为等待是并发的。如果换成同步写法就是十秒。asyncio 要求代码必须是异步风格——用async def定义协程用await等待。同时需要配套的异步库比如aiohttp而不是requests。从同步代码改造成异步代码有一些学习成本但对高频网络调用的场景收益非常可观。我的经验是新项目如果明确是重 I/O 场景直接上 asyncio老项目改造成本高则先用多线程顶住。4.4 并发不是万能的什么时候不该用并发听起来很美好但用错地方会适得其反。我整理过一张简易决策表任务类型推荐方案不推荐的方案CPU 密集大量计算multiprocessing / 进程池threading受 GIL 限制I/O 密集网络、文件、数据库asyncio 或 threading同步串行任务粒度极小毫秒级串行执行任何并发方案有大量共享可变状态优先重构multiprocessing共享难记住一点并发提升的是吞吐量而不是单个任务的速度。如果你的瓶颈是“某个函数单次执行太慢”并发救不了你那需要的是算法优化或后续要讲的 JIT 加速。5. 更进一步Numba、PyPy 与 C 扩展的进阶选择当纯 Python 写法已经榨干容器选对了循环也优化到位了某些计算密集场景依然不达标。这时候就轮到运行时层面的加速手段登场。5.1 Numba给数值计算装上 JITNumba 是一个 JIT即时编译库它把带有jit装饰器的 Python 函数通过 LLVM 编译成机器码。核心优势是你基本不用改代码逻辑只是加一个装饰器循环密集的数值计算就能获得接近 C 语言的速度。from numba import jit jit(nopythonTrue) def sum_squares(n): acc 0 for i in range(n): acc i * i return acc注意nopythonTrue这个参数它强制 Numba 不退回 Python 对象模式只做纯数值编译。开启它之后上面这种循环函数相比纯 Python 往往能快几十倍甚至上百倍。我实际跑过一个蒙特卡洛模拟优化前要几分钟加上jit后几秒就完成。但 Numba 有条件限制它支持的是数值类型和 NumPy 数组不支持大多数字符串操作、类实例、嵌套的动态数据结构。另外第一次调用函数时 JIT 需要编译会有一两秒的“热身”延迟不适合那种只调用一次的小函数。适合的场景是数值计算、数组运算、深层循环的热点函数。5.2 PyPy换个解释器有人欢喜有人愁PyPy 是一个自带 JIT 的 Python 解释器它对纯 Python 代码的加速效果非常显著尤其是那些循环密集、逻辑复杂的纯计算代码经常能比 CPython 快数倍。但选择 PyPy 之前必须想清楚一件事你的项目依赖 C 扩展吗比如 pandas、numpy、scipy 这类库在 PyPy 上的兼容性和性能参差不齐有些甚至无法直接运行。如果你的项目只用了标准库和少量纯 Python 包PyPy 几乎是无痛升级如果重度依赖 C 扩展生态那它大概率不适合你。另外PyPy 的 JIT 有预热特性短生命周期的小脚本用它反而可能更慢。生产环境要切换解释器务必先跑完整测试和基准。5.3 Cython把 Python 代码编译成 CCython 是一种“Python 的超集”允许你在代码里声明 C 类型然后编译成扩展模块。它是性能调优工具箱里较重的武器但也是“最后冲刺”时确定性最高的方案。一个最简例子把纯 Python 的求和循环变成 Cython# sum_cy.pyx def sum_loop(int n): cdef long acc 0 cdef int i for i in range(n): acc i return acc编译后调用这个函数速度可以接近同样逻辑的纯 C 代码。但代价是构建流程变复杂需要编写setup.py用编译器构建代码可读性下降维护成本上升。我的原则是Cython 只用于已经被剖析确认的、纯 Python 无论如何优化都无法达标的核心热点。不要一开始就想“要不要用 Cython”那相当于为了跑五十米去造一辆车。5.4 性能优化的尽头什么时候该收手“过早优化是万恶之源”这句话被说烂了但它确实是真理。我经历过的性能优化项目里大量时间浪费在优化那些本就无关紧要的函数上。真正的优化流程应该是先写正确、清晰的代码用剖析器找到真实热点然后只对热点做优化。优化到什么程度该收手我的标准很简单收益已经达不到业务要求继续优化边际收益极低优化带来的复杂度已经让代码难以维护剖析确认热点已经转移剩余耗时分布均匀。如果一个请求原本需要 120 毫秒优化到 30 毫秒已经满足性能要求就不必再为了压到 20 毫秒引入 Numba 或 Cython 了。那种“我要把最后 10 毫秒也榨干”的执念往往会让代码变得脆而难懂得不偿失。最后说点我自己的体会。做了这么多年性能优化我见过太多项目在不需要优化的地方花大力气。真正的瓶颈永远要先量化不要猜。我这边的习惯是业务代码先保证正确和可读上线后如果有性能问题用 cProfile 抓热点针对那一两个函数做优化优化完写一个小的基准脚本把优化前后的数据留档方便以后 review 和回归。这套流程看起来朴素但长期来看是效率最高的路线。希望这篇文章里的方法能帮你的 Python 代码实实在在地快起来。