Python性能优化需结合解释器行为、内存模型与瓶颈分析；timeit易失真，应优先用cProfile和line_profiler定位真实热点；列表扩容、lru_cache滥用、CPython固有开销是常见陷阱。
Python性能优化不是靠堆砌技巧，而是理解解释器行为、内存模型和常见瓶颈的组合。没有“万能加速方案”，但有几条路径能覆盖 90% 的实际场景。
为什么 timeit 测出来的快，线上反而更慢？
本地单次调用 timeit 忽略了 GC 压力、缓存预热、多线程竞争和系统调度抖动。尤其当代码涉及 I/O、字典扩容或对象频繁创建时，timeit 结果会严重失真。
- 用
python -m cProfile -s cumulative your_script.py替代纯timeit，看真实调用栈耗时分布 - 对关键函数加
@profile（需line_profiler），定位到某一行的 CPU 占用 - 生产环境优先用
psutil监控memory_info().rss和cpu_percent()，而非仅看执行时间
list.append() 很快，但为什么批量追加还卡？
单次 append 是均摊 O(1)，但底层数组扩容（reallocate）是 O(n)。如果初始容量太小，反复扩容会引发大量内存拷贝——比如从空列表开始追加 100 万个元素，可能触发 20+ 次扩容。
- 预先用
[None] * n或list(range(n))占位，再按索引赋值（适用于长度确定场景） - 用
collections.deque替代list做高频插入/追加（无扩容开销，但随机访问变慢） - 避免在循环里写
result = result + [item]—— 这是 O(n²)，每次生成新列表
为什么用了 functools.lru_cache 反而更耗内存？
lru_cache 缓存的是函数调用的 *全部参数组合* 对应的返回值。如果参数含不可哈希类型（如 dict、list），会直接报 TypeError；如果参数是大型对象（如 pandas DataFrame、numpy array），缓存本身就会吃光内存。
立即学习“Python免费学习笔记（深入）”；
- 只对纯函数（无副作用、输入决定输出）且参数轻量（int/str/tuple）启用
lru_cache - 设
maxsize=128或更小，避免无限制增长；设为None时等于无限缓存，风险极高 - 用
cache_info()定期检查命中率：if cache_info().misses > cache_info().hits * 5，说明缓存基本没起作用
CPython 中哪些操作真正“不可优化”？
有些性能短板来自 CPython 设计本身，绕不开，只能换策略：
-
for i in range(10**7):——range对象虽不占内存，但 Python 字节码仍要逐次装入i并做引用计数，比 C 循环慢数十倍；改用numpy.arange()+ 向量化 - 频繁属性访问（如
obj.x、obj.y）—— 每次触发 descriptor 查找；热点代码中提前解包：x, y = obj.x, obj.y - 全局变量读取（如
math.sqrt）—— 每次都要走模块命名空间查找；改为局部导入：from math import sqrt或sqrt = math.sqrt
def hot_loop(data):
# ❌ 慢：反复查 math 模块 + 全局变量
import math
result = []
for x in data:
result.append(math.sqrt(x))
return result
<p>def hot_loop_fast(data):</p><h1>✅ 快：局部变量 + 避免 append 扩容</h1><pre class='brush:python;toolbar:false;'>from math import sqrt
sqrt_data = [sqrt(x) for x in data] # 列表推导自动预估容量
return sqrt_data真正卡住性能的，往往不是某行代码多慢，而是你没意识到它被调用了多少次、参数是否稳定、内存是否在悄悄泄漏。先抓 cProfile 输出里 top 3 函数，再看它们的参数特征和调用上下文——这比背优化口诀有用十倍。
