cProfile前需先用strace -c区分CPU/I/O瓶颈；list.append通常比预分配快；lru_cache需确保参数可哈希；NumPy向量化对小数组可能更慢。
用 cProfile 前先确认瓶颈真在 Python 层
很多人一觉得慢就跑 cProfile，结果发现 time.sleep 占 90% 时间，或者 requests.get 耗时最长——这些根本不是 Python 执行慢，而是 I/O 等待。真正该优化的是网络超时、连接复用、DNS 缓存，不是把 for 改成 map。
实操建议：
- 先用
strace -c python script.py看系统调用耗时分布，区分 CPU-bound 和 I/O-bound - 对 HTTP 请求，加
timeout=(3, 7)并用requests.Session()复用连接 - 数据库慢查优先看
EXPLAIN和索引，不是改 Python 循环写法
list.append 比预分配快？别信直觉
“预分配列表长度能避免扩容”听起来合理，但 CPython 对 list.append 做了高度优化：倍增扩容策略 + 内存预留，实际中多数场景下比 [None] * n 预分配更快，尤其当最终长度不确定或存在条件跳过时。
容易踩的坑：
立即学习“Python免费学习笔记（深入）”；
- 预分配后用
result[i] = x，但 i 不连续（比如过滤逻辑），导致大量None占位和后续清理开销 -
[None] * n创建的是浅拷贝，若元素是可变对象（如[{}]*n），所有项引用同一字典 - 预分配只在长度确定且接近最终大小时有微弱优势；现代解释器下差异常小于 5%
用 functools.lru_cache 前检查参数是否可哈希
缓存失效不是因为“没命中”，而是抛 TypeError: unhashable type——比如传了 dict、list 或自定义类实例进去。错误常被静默吞掉（尤其在装饰器嵌套时），导致你以为缓存生效了，其实每次都在重新计算。
使用场景与对策：
- 参数含字典？转成
frozenset(d.items())或tuple(sorted(d.items())) - 含 NumPy 数组？不能直接缓存，改用
array.tobytes()+array.shape构造键 - 缓存键过大（如长字符串）会拖慢哈希计算，此时不如手动用
dict+id()或业务 ID 控制
NumPy 向量化不是万能解药
把 for 循环改成 np.array + 向量化函数，性能可能反而下降。典型原因是：小数组（np.where 嵌套多层条件）。
关键判断点：
- 用
%timeit对比，且测试数据规模贴近真实场景（别只用 10 个数测） - 检查 dtype：
arr.dtype == object时，NumPy 失去加速意义，甚至比纯 Python 慢 - 内存占用翻倍？向量化常需临时数组，小内存机器上可能触发频繁 GC 或 swap
复杂点在于：性能拐点不固定——同一段代码，在 i5 笔记本上 NumPy 快，在 ARM 服务器上可能 Python+math 更稳。别抽象谈“应该用哪个”，得测，而且得测你的数据、你的硬件、你的 Python 版本。
