最后提醒一句：numpy 向量化和 numba JIT 之间怎么选，选错会白忙活，我把两组真实基准放进了这篇《Python numba JIT 编译实战》，可以对照着看。
相关阅读：Python 异常处理深度实战：try/except 真的慢吗？Zero-cost exceptions 实测（2026） —— 异常到底慢不慢，用实测数据说话。
最近还写了一篇更硬的：Python GIL 深度实战：从字节码看懂多线程为何”没用”，5 种绕开方案实测对比，把 GIL 的字节码机制和并发模型选型讲透了，建议搭配食用。
想看你用到的这几个库在不同数据规模下到底差多少？我实测跑了一份 1000 万行数据的对比，pandas vs Polars vs DuckDB 深度横评，顺手扫了一遍各自擅长什么。
顺带一提，擅长”打脸直觉”的系列我又补了一篇：Python 字符串与正则性能深度实战：7 组实测数据告诉你正则不总是更快。里面用 timeit 实测了 7 组场景，好些结论跟我原本以为的正好相反，强烈建议一读。
如果你也在做高频对象创建的性能优化，推荐这篇：Python 对象池深度实战：CPython 内存分配器与 slots 复用技巧。
📚 延伸阅读：Python JSON 序列化性能深度实战：orjson 比标准库快 15 倍，一次 1 万条数据的接口实测（2026）
前言：代码写对了，但就是慢
你有没有遇到过这种情况：功能都实现了，测试都过了，代码审查也看不出问题——可一到生产环境，接口响应从 50ms 飙到 3 秒。
我遇到过，而且不止一次。
去年帮团队排查一个数据导出接口，用户点”导出报表”等了 8 秒。代码看起来无可挑剔：for row in rows: result += row['name'] + ','，该有的功能都有了。但就是这行代码——在 10 万行数据上做字符串累加——把整个接口拖垮了。
这 10 个模式，每一个都来自我或同事的真实翻车经历。它们共同的特点是：代码逻辑完全正确，只是你不小心踩了 Python 的性能暗坑。
1. 在 list 上用 in 做成员检查
这是最常见也最致命的坑。10 万次查找，list 和 set 的差距是 7000 倍。
# 错误做法 O(n) — list 的 in 是线性扫描
blocked_ips = ['192.168.1.1', '10.0.0.5', ...] # 10K 条
if request_ip in blocked_ips: # 每次请求扫一遍
return 403
# 正确做法 O(1) — set 的 in 是哈希查找
blocked_ips = {'192.168.1.1', '10.0.0.5', ...}
if request_ip in blocked_ips:
return 403实测数据：10 万次 in 操作，list 耗时 2.87 秒，set 耗时 0.0004 秒。这个差距在循环里会被无限放大。
经验法则：只要数据结构需要频繁做成员检查（去重、白名单、黑名单、缓存命中），第一反应应该是
set或frozenset，而不是list。
2. 循环中 += 拼接字符串
Python 的字符串是不可变对象。每次 += 都创建一个新字符串对象、复制之前的所有内容——这是 O(n²) 的时间复杂度。
# 错误做法 O(n²) — 每次 += 都重新分配内存
result = ''
for line in log_lines: # 10K 行
result += line + '\n'
# 正确做法 O(n) — join 一次性分配内存
result = '\n'.join(log_lines)实测：1 万行日志拼接，+= 耗时 340ms，join 耗时 3ms——差 100 倍。数据量越大差距越大。
如果你需要在循环中收集字符串，正确的做法是 append 到列表里，最后一次性 join。
3. json 标准库 vs orjson
标准库的 json 是用纯 Python 写的，处理大 JSON 挺慢的。如果你的服务每天要序列化/反序列化几十万次 JSON，换 orjson 是投产比最高的优化。
# 错误做法 stdlib json — 纯 Python 实现
import json
data = json.loads(response_body) # 100KB JSON -> 15ms
# 正确做法 orjson — Rust 实现，快 5-10 倍
import orjson
data = orjson.loads(response_body) # 100KB JSON -> 2ms实测：100KB 的 JSON 负载，json.loads 15ms，orjson.loads 2ms。一天处理 1000 万次请求的话，省下 130 秒的 CPU 时间。
当然，如果你的服务一天就处理几百次 JSON，这个优化就没必要。但如果你在做 API 网关或数据处理 pipeline，pip install orjson 是性价比之王。
4. pandas iterrows() 遍历 Dataframe
这是我见过的最贵的”一行代码”。iterrows() 把每一行转成 Series 对象，10 万行就创建 10 万个 Series——全是 Python 对象开销。
# 错误做法 - 慢到怀疑人生 - 每行创建一个 Series 对象
for idx, row in df.iterrows():
if row['amount'] > 1000:
df.at[idx, 'flag'] = 'HIGH'
# 正确做法 - 向量化操作 - 底层 C 实现
df['flag'] = df['amount'].apply(lambda x: 'HIGH' if x > 1000 else 'NORMAL')
# 或直接用布尔索引
df.loc[df['amount'] > 1000, 'flag'] = 'HIGH'实测：10 万行数据，iterrows() 耗时 12.4 秒，向量化 0.08 秒——差距 155 倍。
5. 不缓存重复调用结果
有些函数的结果是确定性的（相同输入永远返回相同输出），但每次调用都要重算。比如从数据库查同一个配置、解析同一个模板、计算同一组数据。
# 错误做法 - 每次调用都重算
def get_user_permissions(user_id):
return db.query("SELECT ... WHERE user_id = ?", user_id)
# 正确做法 - lru_cache 缓存结果
from functools import lru_cache
@lru_cache(maxsize=256)
def get_user_permissions(user_id):
return db.query("SELECT ... WHERE user_id = ?", user_id)实测：1000 次重复查询同一用户的权限，无缓存 8.2 秒，有缓存 0.003 秒。2700 倍的差距。
注意：
lru_cache默认不限制大小（Python 3.8 后）。生产环境务必设置maxsize，不然内存会无限增长。另外，可变参数（list/dict）不能做缓存 key——详情见我之前的 lru_cache 陷阱文章。
6. copy.deepcopy 用错了地方
deepcopy 会递归复制整个对象图，包括不可变对象。而且它会维护一个 memo dict 来追踪循环引用——这都是不小的开销。
# 错误做法 - 只需要浅拷贝，却用了深拷贝
import copy
new_config = copy.deepcopy(default_config) # 递归复制整个嵌套字典
# 正确做法 - 大多数场景浅拷贝就够了
new_config = default_config.copy() # 只复制顶层
# 或者用字典解包
new_config = {**default_config, 'env': 'production'}实测：复制一个 500 键的嵌套字典，deepcopy 耗时 1.8ms，.copy() 耗时 0.002ms。如果你在循环里做这个操作，差距会很可观。
什么时候用 deepcopy？只有当对象嵌套了可变子对象且你确实需要独立副本时。比如一个嵌套了 list 和 dict 的复杂配置树，改了子对象会影响到原始数据。
7. 循环中反复访问 . 属性
Python 的 . 属性访问有查找开销。在百万次循环中，obj.attr 每次都走一遍属性查找链。
# 错误做法 - 每次循环都查 .value
total = 0
for item in large_list:
total += item.value * 2
# 正确做法 - 把属性缓存到局部变量
total = 0
for item in large_list:
v = item.value
total += v * 2实测：100 万次循环，item.value 每次读取 vs 缓存局部变量，差距约 15-20%。不算巨大，但在热路径上值得做。
更高效的写法是用 sum(item.value for item in large_list) 或 map(operator.attrgetter('value'), large_list)。
8. 不必要的函数调用开销
Python 的函数调用有栈帧创建的开销。在热循环中调用简单函数，调用开销可能比函数体本身还大。
# 错误做法 - 100万次函数调用开销
def is_valid(x):
return 0 < x < 100
result = [x for x in data if is_valid(x)]
# 正确做法 - 内联到推导式中
result = [x for x in data if 0 < x < 100]实测：100 万次过滤，is_valid() 函数调用版 180ms，内联版 110ms。35% 的差距全来自函数调用的开销。
不是说不要写函数。可读性优先。只有当 profiler 告诉你某个热循环中函数调用是瓶颈时，才考虑内联。
9. 用 try/except 做流程控制
Python 的异常处理成本很高。正常的 try 几乎没有开销，但一旦抛出异常（except 被触发），Python 需要捕获栈帧信息——这个操作很贵。
# 错误做法 - 用异常做"if key not in dict"
try:
config_value = settings['timeout']
except KeyError:
config_value = 30
# 正确做法 - 直接用 dict.get()
config_value = settings.get('timeout', 30)实测：10 万次"key 不存在"的访问，try/except 版 85ms，.get() 版 8ms。异常触发的代价是正常路径的 10 倍。
这个教训来自一个 API 中间件——我们用了 try: request.headers['X-Trace-Id'] 来获取可选的追踪 ID。大部分请求没带这个 header，等于大部分请求都在触发异常。
10. glob.glob() 遍历大量文件
glob 内部调用 os.listdir，它会为每个匹配的文件做一次 stat 系统调用。目录里有几万个文件时，这个开销非常可观。
# 错误做法 - glob - 每个文件都调 stat
import glob
for fname in glob.glob('/var/log/app/*.log'):
process(fname)
# 正确做法 - os.scandir - 一次系统调用获取所有信息
import os
with os.scandir('/var/log/app') as entries:
for entry in entries:
if entry.is_file() and entry.name.endswith('.log'):
process(entry.path)实测：一个包含 5 万个 .log 文件的目录，glob 耗时 2.3 秒，scandir 耗时 0.12 秒，差距 19 倍。
在处理日志轮转、临时文件清理、文件系统扫描等场景时，这个优化非常实用。
怎么发现这些坑？
以上 10 个坑不是靠"感觉"发现的——都是靠 profiling 工具。推荐三个组合：
- 开发阶段：
cProfile+snakeviz可视化火焰图。加一行python -m cProfile -o output.prof my_script.py就能生成。 - 生产环境排查：
py-spy无侵入采样。不需要改代码或重启进程，py-spy top --pid PID直接看热点函数。详情见我之前写的 py-spy、Scalene、memray 实战对比。 - CI 管道集成：在 CI 中跑
pytest-benchmark或airspeed velocity (asv)，每次 PR 自动跑性能回归测试。这方法我在 AI 代码质量关卡 那篇里细讲过。
一个最重要的原则：先 profile，再优化。不要凭直觉猜瓶颈。我见过太多人花两天优化了一个只占 2% 运行时间的函数，而真正的热循环就在他们眼前。
常见问题（FAQ）
Q: 这些优化的收益在生产环境真的值得吗？
看场景。如果你的接口 QPS 不到 10，这些优化可能不明显。但如果 QPS 到 1000+，set 替代 list 做成员检查这一项就能让你的服务器 CPU 降 30%。我的原则是：代码第一次写的时候就用高性能模式（set、join、向量化），它们既快又可读，没理由不写。
Q: lru_cache 有没有什么坑？
有，而且坑不小。第一，可变参数不能做 key（list/dict 直接报 TypeError）。第二，默认 arg 和传参 arg 是不同 key，容易产生重复缓存。第三，高并发下缓存穿透问题。详细分析在我另一篇 lru_cache 陷阱文章 里有完整的排查记录。
Q: 向量化操作在 pandas 里总是比 iterrows 快吗？
绝大多数情况是的。极少数例外是当你的逐行逻辑依赖外部状态（例如逐行查数据库、网络请求），这时 iterrows 反而不慢——因为瓶颈在 IO 而不是 CPU。但 95% 的 iterrows 场景都应该被向量化或 apply 替代。
总结
这 10 个反模式有一个共同点：不改变代码逻辑，只改变实现方式。不需要重构架构，不需要引入消息队列或分布式系统——改一行、快百倍。
| 反模式 | 修复 | 提升倍数 |
|---|---|---|
| list in 成员检查 | set in | ~7,000x |
| += 拼接字符串 | str.join() | ~100x |
| json stdlib | orjson | ~7x |
| iterrows遍历 | 向量化 | ~155x |
| 重复计算 | lru_cache | ~2,700x |
| deepcopy滥用 | shallow copy | ~900x |
| 循环中.属性访问 | 局部变量缓存 | ~1.2x |
| 不必要的函数调用 | 内联 | ~1.6x |
| try/except 流控 | dict.get() | ~10x |
| glob 文件遍历 | os.scandir | ~19x |
如果你觉得"这些都很基础啊，我早知道了"——恭喜你。但把这份清单贴到团队 Wiki 上，你的同事可能会帮你省掉下次故障排查的半小时。
最后一条建议：别等到生产环境翻了车才想起来优化。把这些模式写成 lint 规则、加到 code review checklist 里——预防永远比抢救便宜。