本文深入剖析了Python性能优化的三大关键实践：局部变量访问比全局变量快2–5倍，源于LOAD_FAST与LOAD_GLOBAL字节码指令的本质差异，建议将高频使用的全局对象（如math.sin、正则编译结果）提前缓存为局部变量；循环中应杜绝字符串累加、重复类型检查和冗余索引操作，改用join、预检和直接迭代等高效模式；生成器虽能节省内存，但仅适用于大数据流式处理或部分消费场景，对小数据全量消费反而因yield调度开销而拖慢整体性能——这些并非纸上谈兵的“微优化”，而是在高频循环中立竿见影的实战准则。

为什么局部变量比全局变量快？

Python 访问局部变量走的是 LOAD_FAST 指令，而全局变量是 LOAD_GLOBAL，后者要遍历模块字典、可能触发属性查找，慢 2–5 倍。这不是“微优化”，在高频循环里会明显拖累。

实操建议：

• 把频繁使用的全局对象（如 math.sin、re.compile() 的结果）提前赋值给函数内变量
• 避免在循环中重复写 import os 或 from json import loads —— 导入本身不耗时，但引用时若没缓存，会多一次命名空间查找
• 用 dis.dis() 看字节码验证：局部变量对应 LOAD_FAST，全局/内置名是 LOAD_GLOBAL 或 LOAD_BUILTIN

for 循环里哪些操作最伤性能？

真正拖慢循环的往往不是迭代本身，而是每次迭代中隐式开销大的操作。比如反复调用方法、拼接字符串、做类型检查。

常见错误现象：

• result += item 在循环中拼接字符串 → 触发多次内存分配和拷贝（O(n²)）
• if isinstance(obj, list): ... 放在内层循环 → 每次都走类型系统路径
• for i in range(len(data)): 再用 data[i] → 多一次索引查找 + len() 调用（虽有优化，但不如直接迭代）

改法示例：

# 慢
s = ""
for x in items:
    s += str(x)
快
s = "".join(str(x) for x in items)

生成器什么时候该用、什么时候不该用？

生成器节省内存，但未必省时间。它把计算延迟到取值时，如果所有值最终都要被消费，且中间没有过滤/截断，那生成器反而增加函数调用开销（yield 是协程调度点）。

使用场景判断：

• 适合：数据源巨大、只需前 N 项（itertools.islice(gen, 100)）、或需流式处理（边读文件边解析）
• 不适合：小列表（gen[5] 不支持）、或后续要多次遍历（生成器只能用一次）
• 注意：list(gen) 会立刻耗尽生成器并分配全部内存，等于白用

一个易忽略点：yield from 在嵌套生成器时比手动 for...yield 快约 10%——Cython 编译后差距更大。

profile 之前别猜，但 profile 之后别只看总时间

用 cProfile.run('foo()') 或 line_profiler 才能定位真实瓶颈。很多人优化了 math.sqrt() 调用，却没发现 90% 时间花在 json.loads() 的字符串解码上。

关键提醒：

• 局部变量优化只有在函数被高频调用（如每秒数千次）时才值得单独提取
• 生成器的 yield 开销约 50–100ns，单次不明显，但嵌套三层+每秒百万次就不可忽视
• for x in iterable 的底层是 iter() + next()，如果 iterable 是自定义类，__iter__ 和 __next__ 实现质量直接影响性能

理论要掌握，实操不能落！以上关于《Python优化：局部变量与循环技巧解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！