《Python 从入门到精通》139|性能优化思路:先定位瓶颈,再谈优化

一、很多人一提优化，第一反应就错了

程序一慢，很多初学者马上会做三件事：

改写法 上多线程 换更复杂的技术

看起来很积极，实际上往往是在瞎忙。

因为性能优化最怕的，不是你不会高级技巧，而是你还没搞清楚程序到底慢在哪，就开始乱改。结果常常是：

代码变复杂了 可读性变差了 Bug 变多了 速度却没提升多少

所以真正靠谱的优化顺序，永远不是先动手，而是先判断。

先找到瓶颈 再分析原因 最后才决定怎么优化

这句话你现在记住，后面会省掉很多弯路。

二、什么叫瓶颈

瓶颈这个词，在性能优化里非常关键。

它指的是整条执行链路里最慢、最卡、最拖后腿的那一段。

你可以把程序想象成一条流水线。

前面几步都很快 后面几步也不算慢 但中间有一步特别慢

那最终整体速度，就会被这一步死死卡住。

就像你去食堂打饭，盛饭很快，刷卡很快，端餐盘也很快，但打菜窗口只有一个人，每个人都要停很久，那整条队伍就会堵在这里。

这个打菜窗口，就是瓶颈。

程序也是一样。

不是所有地方都值得优化。 真正值钱的优化，是盯着最慢的那一段下手。

三、为什么一定要先定位，而不是先优化

因为程序慢的原因可能完全不同。

有时候是循环太多。 有时候是算法太笨。 有时候是列表查找用了不合适的数据结构。 有时候是数据库查询慢。 有时候是网络请求慢。 有时候是文件读写慢。 有时候只是日志打印太多。

如果你没定位就乱优化，结果很可能是：

真正慢的是数据库查询，你却在改 Python 循环 真正慢的是网络等待，你却去研究多进程 真正慢的是字符串拼接，你却去调线程数 真正慢的是磁盘读写，你却去优化数学计算

方向错了，再努力也没用。

所以优化最重要的，不是动作快，而是判断准。

四、优化最经典的误区：盯着自己看得见的地方改

为什么很多人容易优化错方向。

因为人天然会盯着“看起来复杂”的代码。

比如一段嵌套循环，看着就很重，于是你怀疑它慢。 但真正耗时的，可能是循环里那句数据库查询。 或者真正耗时的是循环外的文件读取。 又或者最慢的是某个接口请求。

也就是说，代码“长得复杂”，不等于它最慢。 代码“看起来简单”，也不等于它很轻。

性能优化不能靠视觉判断。 必须靠测量和定位。

五、先学会把慢分成几类

定位瓶颈之前，先把程序慢的大类分清楚。

常见性能问题，大致可以分成下面几类。

1. CPU 密集型

特点是程序一直在算。 比如大量循环、复杂数学运算、图像处理、文本统计、排序、加密。

这种慢，本质上是算力压力大。

2. I/O 密集型

特点是程序一直在等。 比如网络请求、读写文件、数据库访问、接口调用、磁盘操作。

这种慢，本质上不是 Python 执行慢，而是外部资源返回慢。

3. 数据结构不合理

比如本来应该用集合查找，你却一直用列表遍历。 本来可以字典映射，你却每次都线性搜索。

这种慢，往往不是任务太难，而是工具选错了。

4. 重复劳动太多

比如循环里反复打开文件、反复连数据库、反复做相同计算、反复请求同一个接口。

这种慢属于典型的人为浪费。

5. 不必要的对象创建和数据复制

比如大列表反复切片、频繁拼接字符串、生成很多临时对象、无意义地深拷贝数据。

这种问题在数据量变大后会特别明显。

先会分类，后面你看到程序慢时，脑子里才不会一团乱。

六、优化的第一原则：不要凭感觉，先测

性能优化里有一句非常经典的话：

不要猜，去测。

因为人的感觉经常不准。 你以为慢的是 A，结果真正慢的是 B。 你以为某段代码很重，结果它只占 5% 时间。 你以为自己优化成功了，结果前后差距几乎可以忽略。

所以，优化之前最基本的动作就是记录时间。

最简单的方式：

import timestart = time.time()total = 0for i in range(10000000):    total += iend = time.time()print("耗时：", end - start)

这样至少你能知道整段代码花了多久。

如果程序由多部分组成，那就分段测。

import timestart = time.time()print("开始读取文件")t1 = time.time()# 文件读取逻辑t2 = time.time()print("读取耗时：", t2 - t1)print("开始处理数据")t3 = time.time()# 数据处理逻辑t4 = time.time()print("处理耗时：", t4 - t3)print("开始写入结果")t5 = time.time()# 写入逻辑t6 = time.time()print("写入耗时：", t6 - t5)print("总耗时：", t6 - start)

这样你就能立刻看到，到底是读慢、算慢，还是写慢。

七、先分段，再细化，这是最实用的定位方法

很多新手一测性能，就想直接精确到每一行。 其实没必要。

更好的思路是：

先粗定位 再细定位

比如一个程序分成三段：

读取数据 处理数据 输出结果

你先看看哪一段最慢。 如果发现处理数据最慢，再进一步拆：

清洗字段 去重 排序 统计 格式化输出

然后继续看哪一步最重。 慢慢往下钻，直到找到那个真正最值得改的点。

这个方法非常实用，因为它避免了你一开始就陷进细节海洋里。

先大块切 再逐层深入 这才是靠谱的定位方式

八、一个很典型的错误案例：以为是算法慢，其实是打印慢

看一段代码：

for i in range(100000):    print(i)

很多人会觉得，这不就是个简单循环吗。 还能慢到哪去。

但实际运行时，它可能比你想象中慢很多。 慢的原因不是循环本身，而是大量打印输出。

也就是说，瓶颈根本不在 for，而在 print()。

这个例子很重要，因为它说明一件事：

慢点可能藏在你最没当回事的地方。

你以为程序在忙着算，实际上它只是在疯狂往终端写内容。 所以性能定位一定要看事实，不要只看表面结构。

九、另一个常见案例：循环不一定慢，循环里的操作才决定生死

很多人一看到循环就紧张，好像循环本身就是罪魁祸首。

其实循环本身是不是瓶颈，要看里面做了什么。

比如这个循环：

total = 0for i in range(1000000):    total += i

它确实在做很多计算。

但如果你写的是下面这种：

for user_id in user_ids:    result = requests.get(f"https://example.com/user/{user_id}")

那真正慢的根本不是 for，而是每次循环里都在发网络请求。

再比如：

for item in items:with open("data.txt", "r", encoding="utf-8") as f:        content = f.read()

这里最慢的也不是循环，而是反复打开文件。

所以你要慢慢形成一种判断力：

循环只是外壳。 里面干了什么，才决定它到底慢不慢。

十、优化前，先问这四个问题

这是非常实战的一组问题。

当你发现程序慢时，先别急着改，先问自己：

第一，慢的是哪一段 第二，这一段是算得多，还是等得多 第三，这个慢点占整体时间比例多大 第四，这个地方真的值得优化吗

尤其是第四个问题，很容易被忽略。

假设一个程序总共运行 30 秒。 你发现其中一段耗时 0.2 秒。 哪怕你把它优化到 0.05 秒，整体也几乎没感觉。

反过来，如果某个数据库查询占了 18 秒，那哪怕只优化一半，提升都非常明显。

所以优化不只是技术问题，更是投入产出比问题。

十一、最容易立竿见影的优化，通常不是高级技巧

很多人觉得性能优化一定要会很深的技术，其实很多时候最有效的优化，反而特别朴素。

比如：

少做重复计算 减少重复 I/O 换合适的数据结构 避免在循环里做昂贵操作 缓存重复使用的结果 减少不必要的字符串拼接 批量处理代替逐条处理

看一个小例子。

低效写法：

result = ""for i in range(10000):    result += str(i)

更合理的写法：

parts = []for i in range(10000):    parts.append(str(i))result = "".join(parts)

这个优化没有任何高深概念，但在大量字符串处理时就会明显更稳。

所以不要一上来就想着线程池、协程池、分布式。 很多程序的第一轮性能提升，靠的就是把低效写法改顺。

十二、数据结构选错，优化再多都很难救

这个问题非常常见，而且很多人一开始意识不到。

比如你要反复判断一个元素是否存在。 列表写法：

nums = list(range(100000))target = 99999if target in nums:    print("找到了")

集合写法：

nums = set(range(100000))target = 99999if target in nums:    print("找到了")

两段代码逻辑看起来差不多。 但在大量查找场景里，性能表现可能差很多。

这说明一个事实：

性能优化很多时候不是“把代码写得更炫”，而是“把基础选型做对”。

你要是工具都选错了，后面再加线程、再调参数，收益也会很有限。

十三、缓存，是最实用也最容易见效的优化思想之一

有些结果算一次就够了，没必要每次都重新算。

这就是缓存思维。

比如：

defget_config():with open("config.json", "r", encoding="utf-8") as f:return f.read()for i in range(1000):    content = get_config()

如果配置文件根本不会变，这种写法就很浪费。 更合理的是读一次，后面反复用。

defget_config():with open("config.json", "r", encoding="utf-8") as f:return f.read()content = get_config()for i in range(1000):# 使用 contentpass

缓存不一定非要多高级。 哪怕只是把重复读取、重复计算、重复解析的结果先存起来，也常常能明显提速。

但要注意，缓存不是越多越好。 缓存会占内存，也要考虑数据是否可能变。

十四、批量处理，往往比逐条处理更高效

很多程序慢，不是因为单次操作慢，而是因为重复次数太多。

比如你要往数据库插入 10000 条记录。 如果一条一条插，而且每条都单独提交事务，那通常会非常慢。

如果改成批量插入，速度往往会好很多。

文件写入也是同理。 网络请求也是同理。 日志处理也是同理。

本质上，批量处理是在减少“每次启动一次操作”的额外开销。

所以当你发现程序在做大量重复型动作时，一定要问自己一句：

这件事能不能攒一批再做。

这个问题非常值钱。

十五、并发不是默认答案，别一慢就上线程或协程

这是很多人最容易冲动的地方。

程序慢 那就多线程 再不行就异步 再不行就多进程

听起来很有战斗力，但经常方向不对。

如果慢在数据库没建索引，你开 20 个线程只会把数据库压得更惨。 如果慢在磁盘读写，开再多协程也不会让机械硬盘突然起飞。 如果慢在算法复杂度高，线程只能把低效算法并发执行，本质问题还在。

所以并发优化必须排在定位之后，而不是排在第一反应里。

先确认它真的是等待型瓶颈、且任务可以并发，才值得考虑线程或协程。 先确认它真的是计算瓶颈且能拆分，才值得考虑多进程。

十六、优化不是只看速度，还要看代价

很多人只看“快没快”，却不看代价。

比如你为了提速 10%，让代码复杂了三倍。 后面任何人维护都很痛苦。 或者你为了省 1 秒，引入了复杂缓存机制，结果数据一致性开始出问题。

这时候就要问一句：

这点性能收益，值不值得付这么大复杂度成本。

真正成熟的优化，不是单看性能数字，而是综合看：

提升有多大 改动有多大 风险有多大 维护成本会不会飙升 这个程序是否真的需要这么快

不是所有项目都值得极限优化。 很多时候，稳定、清晰、够快，才是最优解。

十七、一个完整的优化思路案例

假设你有一个脚本，要做三件事：

读取 500 个日志文件 提取错误信息 汇总写入报告

现在程序跑起来很慢。 正确的优化思路应该是这样：

第一步，先测总耗时 确认到底慢到什么程度

第二步，分段测 看看是读文件慢、文本处理慢，还是写报告慢

第三步，继续细拆 如果发现是文本处理慢，再看是正则太慢、字符串操作太慢，还是重复遍历太多

第四步，判断问题类型 如果慢在磁盘读取，那偏 I/O 如果慢在文本统计，那偏 CPU 如果慢在重复打开文件，那偏写法问题 如果慢在查找结构，那偏数据结构问题

第五步，再决定手段 如果慢在 I/O 且任务独立，可以考虑线程或协程 如果慢在纯计算，可以考虑多进程或算法优化 如果慢在重复处理，可以考虑缓存或批量处理 如果慢在数据结构，优先换结构

你会发现，这整套流程里，并发工具根本不是起点。 定位才是起点。

十八、性能优化中，算法复杂度往往是最硬核的影响因素

这一点必须提一下。

有时候程序慢，不是因为 Python 慢，也不是因为 I/O 慢，而是因为算法复杂度太高。

比如双重循环查重：

nums = [1, 2, 3, 2, 5, 6]for i in range(len(nums)):for j in range(i + 1, len(nums)):if nums[i] == nums[j]:            print("有重复")

数据量小时没感觉。 数据量一大，速度就会明显下降。

如果改成集合思路，复杂度会更合理。

nums = [1, 2, 3, 2, 5, 6]if len(nums) != len(set(nums)):    print("有重复")

所以你要知道，真正大的优化，有时候不是微调代码，而是换一种思路。

算法层面的优化，常常比语法层面的优化更值钱。

十九、微优化可以做，但不要本末倒置

所谓微优化，就是一些很细枝末节的小技巧。

比如：

局部变量访问稍快 某些写法更简洁 某些内置函数更高效 推导式在某些场景下更紧凑

这些可以学，但别一开始就沉迷。

因为如果你的程序 90% 时间都耗在数据库查询上，那你去纠结某一行是用 append 还是别的写法，意义非常小。

所以优化顺序一定要明确：

先大头 再中头 最后才轮到小头

别把宝贵时间花在不值钱的地方。

二十、什么时候可以停止优化

这是一个经常被忽略，但非常重要的问题。

优化不是没有尽头的。 你总得知道什么时候该收手。

通常可以停止优化的情况有：

程序已经足够快 瓶颈已经不再影响用户体验 继续优化的收益明显变小 继续优化会显著增加复杂度 当前真正的限制已经不在代码层面

比如你把一个脚本从 30 秒优化到 5 秒，这已经是巨大提升。 如果再花三天时间把它从 5 秒抠到 4.6 秒，就要问问值不值。

所以成熟的优化观，不是永远追求更快，而是追求合理。

二十一、一个非常实用的优化顺序清单

以后你自己写程序时，可以按这个顺序来想。

先确认慢不慢 再确认慢在哪 再确认属于哪种慢 再判断值不值得优化 再选最合适的方法 最后重新测量，验证是否真的变快

把这六步连起来，就是一套非常稳定的性能优化思路。

你会发现，这里面最重要的动作不是“改代码”，而是“定位和验证”。

二十二、优化后的重新测量，比优化动作本身还重要

很多人改完代码后，心里会觉得：

这下应该快了。

但“应该”不算答案。 必须重新测。

为什么。

因为有时候你改了很多，速度没变。 有时候你以为更快了，其实只是一次偶然。 有时候局部快了，但整体反而慢了。 有时候速度快了，但内存占用明显暴涨。

所以每次优化后，都要重新记录时间、观察结果。

这才叫闭环。 不然你只是做了修改，不叫完成优化。

二十三、本章要点整理

性能优化的第一原则，不是先改代码，而是先找瓶颈。 瓶颈是整条执行链路里最慢、最拖后腿的部分。 优化不能靠感觉，必须靠测量。 定位时先粗分段，再逐步细化，是最实用的方法。 常见性能问题包括 CPU 密集、I/O 密集、数据结构不合理、重复劳动过多、对象创建和复制过多。 很多有效优化并不高级，往往只是减少重复操作、选对数据结构、加缓存、做批量处理。 并发不是默认答案，只有定位到合适场景才值得使用。 算法复杂度的优化，常常比微调语法更有价值。 优化之后一定要重新测量，不能靠主观感觉判断成效。 优化的目标不是无限追求更快，而是在性能、复杂度、稳定性之间找到合理平衡。