本文目录导读：
- 误区一：过早优化
- 误区二：盲目使用PyPy或C扩展
- 误区三：把所有循环都换成列表推导式或
map/filter - 误区四：使用
for i in range(len(lst))而不是for item in lst - 误区五：过度使用
timeit进行微观优化 - 误区六：忽略函数调用的隐式开销
- 误区七：使用全局变量代替局部变量
- 误区八：轻信“Python慢”就放弃Python
- 正确的优化路径
在Python性能优化中，开发者常常会陷入一些“直觉正确但实际无效甚至有害”的误区,以下是常见的误区及对应的正确思路：
过早优化
- 表现：项目还在原型阶段或功能未验证时，就开始用各种奇技淫巧（如手动内联、预计算、使用
__slots__）来“提升性能”。 - 问题：过早优化往往复杂化代码，降低可读性和可维护性,且优化点可能根本不是瓶颈。
- 正确做法：先用
cProfile或py-spy等工具做性能分析（profiling），找出真正的热点（hotspots），只优化那1%的代码。
盲目使用PyPy或C扩展
- 表现：听说PyPy比CPython快，就把所有代码丢上去跑；或者听说Cython/C扩展快,就到处写C扩展。
- 问题：
- PyPy对纯Python数值运算和循环极快，但不兼容C扩展（如NumPy/Pandas、某些第三方库）,且内存占用更大。
- C扩展在I/O密集型或Python函数调用频繁的代码中可能反而更慢（因为跨语言调用开销）。
- 正确做法：先确认瓶颈是CPU计算密集还是I/O密集，CPU密集且可纯Python实现，可尝试PyPy；若依赖大量C库（如Numpy），CPython+多进程/多线程更优。
把所有循环都换成列表推导式或map/filter
- 表现：认为列表推导式总是比普通
for循环快，于是把嵌套循环、副作用操作也强行改成推导式。 - 问题：
- 当内存无法容纳整个结果时，用推导式会生成巨大列表，反而慢+耗内存；此时应该用生成器表达式。
- 如果循环内有复杂逻辑或函数调用，推导式不会比
for快多少（甚至更慢）,且可读性差。
- 正确做法：对于简单转换/过滤场景，用推导式；对于复杂逻辑或惰性求值，用生成器或
for循环,只在性能热点处优化。
使用for i in range(len(lst))而不是for item in lst
- 表现：像C语言一样用索引遍历列表：
for i in range(len(lst)): print(lst[i])。 - 问题：Python里直接迭代对象比索引快得多（索引需要重复调用
__getitem__，且可能有边界检查成本）。 - 正确做法：除非需要同时使用索引和值（用
enumerate），否则一律用for item in lst。
过度使用timeit进行微观优化
- 表现：对某一行代码用
timeit测试0.001秒的提升,然后重构整段代码。 - 问题：微观优化往往忽略上下文，比如一次函数调用的开销可能被IO、数据库查询或网络延迟稀释到忽略不计，Python虚拟机优化（如JIT、内插缓存）会使微观基准不准确。
- 正确做法：只在实际业务场景下测量性能影响（例如使用真实数据集或负载测试）,避免纯数学运算级别的微调。
忽略函数调用的隐式开销
- 表现：把每个小操作都封装成函数（如
def add(a,b): return a+b），认为“代码整洁”与性能无关。 - 问题：Python函数调用有栈帧创建/销毁开销（约50-100纳秒，但循环内多次调用会累积）。
- 正确做法：在性能关键的热点路径（如每秒运行百万次的内循环）中，考虑内联简单逻辑；但非热点路径保持函数封装以维护可读性。
使用全局变量代替局部变量
- 表现：为了“避免参数传递”，在函数内直接引用全局变量（尤其在内循环里）。
- 问题：全局变量在模块作用域中查找比局部变量慢很多（全局需要字典查找，局部有
LOAD_FAST指令直接操作索引）。 - 正确做法：将全局变量作为参数传入函数，或赋值给局部变量再使用：
local_var = global_var; for i in range(n): ... local_var ...。
轻信“Python慢”就放弃Python
- 表现：觉得“Python是解释型语言，再怎么优化也赶不上C/Java”，于是盲目用子进程+Shell或完全重写。
- 问题：很多改进可以带来数量级提升——例如用NumPy向量化代替
for循环、用多线程处理I/O、用Cython编译热点、用Asyncio处理高并发连接。 - 正确做法：先确认瓶颈是计算密集（用NumPy/PyPy/Cython）还是I/O密集（用异步IO或多线程），然后采用适当的方案,通常能在保持Python开发效率的同时达到足够性能。
正确的优化路径
- 做性能分析（profile）：确定真正耗时的部分（不要猜）。
- 识别瓶颈类型：CPU束缚？内存束缚？I/O束缚？网络束缚？
- 针对性优化：
- CPU密集：换算法（O(n^2) → O(n log n)）、向量化（NumPy）、编译（Cython/Pythran）、PyPy。
- I/O密集：异步（
asyncio）、多线程（concurrent.futures.ThreadPoolExecutor）。 - 内存密集：使用生成器、
__slots__、数据压缩（如array模块或struct）。
- 避免微优化：除非已经优化宏观结构，且毫秒级差异影响业务（如高频交易）,否则不要对单行语法特性斤斤计较。
- 复用和组合：遇到性能墙时，考虑用C扩展（如
pybind11）重写热点，或调用现有高性能库（如Numba、Rust/Python绑定）。
“让代码先跑对，再跑快；跑对后，用数据说话，而不是用感觉优化。”
