局部变量比全局变量快，因python用LOAD_FAST直接索引栈帧，而LOAD_GLOBAL需遍历模块字典；循环中应避免字符串累加、重复类型检查和冗余索引；生成器适合大数据流式处理，小数据全量消费时反增开销。
为什么局部变量比全局变量快？
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 循环里哪些操作最伤性能？
真正拖慢循环的往往不是迭代本身，而是每次迭代中隐式开销大的操作。比如反复调用方法、拼接字符串、做类型检查。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
-
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__实现质量直接影响性能