Python性能优化需基于解释器行为与运行时约束：优先用cProfile和tracemalloc定位真实瓶颈，避免盲目缓存或Cython；预分配列表仅在长度确定时更优；asyncio不加速CPU密集任务，应配合多进程；90%性能问题源于I/O、连接或日志配置。
Python性能优化不是堆砌技巧，而是理解解释器行为、内存模型和运行时约束后的针对性干预。盲目用 @lru_cache 或改写为 cython 常常无效，甚至更慢。
为什么 timeit 测出来的快，线上反而没变化？
本地单次小数据测试掩盖了真实瓶颈：I/O等待、GIL争用、内存分配压力、缓存未命中。生产环境的 timeit 结果往往不可迁移。
- 用
python -m cProfile -s cumulative your_script.py替代timeit，关注cumulative列而非tottime - 对 Web 服务，优先在真实请求路径中注入
tracemalloc，捕获峰值内存分配位置：import tracemalloc tracemalloc.start() # ... run request handler ... current, peak = tracemalloc.get_traced_memory() print(f"Peak memory usage: {peak / 1024 / 1024:.1f} MB") - 避免在循环内反复调用
len()、hasattr()等——它们本身有开销，且可能触发属性查找或方法调用
list.append() 比预分配 list 更快？真还是假？
取决于增长模式。Python 的 list 底层是动态数组，扩容策略是“乘数增长”（约 1.125 倍），摊还复杂度仍是 O(1)，但频繁扩容会引发多次内存拷贝和碎片。
- 已知长度时，用
[None] * n预分配比循环append快 2–3 倍（尤其n > 10^4） - 但若长度不确定，或中间有大量
pop()/insert()，预分配反而浪费内存且易出错 - 替代方案：对追加密集场景，考虑
collections.de（O(1) 头尾操作，无扩容抖动）
que
que为什么用了 asyncio，CPU 密集任务反而更慢？
asyncio 不绕过 GIL，只优化 I/O 等待。CPU 密集型协程仍被串行调度，还额外承担事件循环开销。
- CPU 密集任务必须交给
multiprocessing或concurrent.futures.ProcessPoolExecutor -
asyncio.to_thread()（Python 3.9+）可安全将阻塞调用扔进线程池，但仅适用于真正阻塞、非 CPU 密集的函数（如requests.get、json.loads） - 混合场景（如爬虫）：用
asyncio并发发请求 +ProcessPoolExecutor解析 HTML，两者边界要清晰，避免跨进程传大对象
最常被忽略的一点：90% 的“慢”来自重复加载、冗余序列化、未关闭的数据库连接或日志级别设为 DEBUG。先看 strace -e trace=connect,open,read,write 和 lsof -p $(pidof python)，再谈算法优化。
