局部变量访问比全局变量快2–5倍，因load_fast按栈帧固定索引直接内存寻址，而load_global需哈希计算、字典查找与键比对；可用dis.dis()验证指令差异，且仅在高频访问场景优化才显著。
局部变量访问比全局变量快，不是“稍快一点”，而是底层指令路径完全不同导致的 2–5 倍差距——关键在 LOAD_FAST 和 LOAD_GLOBAL 这两条字节码指令。
为什么 LOAD_FAST 比 LOAD_GLOBAL 快这么多？
Python 在函数编译阶段就确定了所有局部变量在栈帧中的固定索引位置（比如 a 在索引 0，b 在索引 1），运行时直接按数组下标取值，是纯内存寻址，无哈希、无字典、无键比对。
而 LOAD_GLOBAL 每次都要：计算变量名哈希值 → 查找 globals 字典桶 → 遍历冲突链比对字符串键。哪怕字典很小，这个过程的常数开销也远高于数组索引。
你可以用 dis.dis(func) 看到：局部变量对应 LOAD_FAST 0（操作数是整数索引），全局变量对应 LOAD_GLOBAL 'x'（操作数是字符串对象）。
哪些写法会让局部变量“失效”，退化成全局查找？
一旦破坏编译期作用域判断，Python 就会降级为 LOAD_GLOBAL，甚至更慢的路径：
- 在赋值前读取同名变量（如先
print(x)，再x = 1）→ 触发UnboundLocalError或隐式全局引用 - 函数内使用
exec()或eval()→ 编译器无法静态分析作用域 - 显式声明
global x→ 强制走全局路径，读写都绕过局部优化 - 通过
getattr(obj, 'attr')或obj.__dict__['attr']动态访问 → 完全跳过名字绑定机制
实际提速该怎么做，而不是瞎优化？
真正起效的操作非常具体，且只在高频访问场景下有意义：
- 循环里反复用的模块属性（如
math.sqrt）提前赋给局部变量：sqrt = math.sqrt - 配置常量（如
config.TIMEOUT）不要每次都点进去，一次赋值：timeout = config.TIMEOUT - 把顶层脚本逻辑包进函数里——连
for循环本身都受益，因为循环变量i自动变成局部 - 别为了快把大对象（如
pandas.DataFrame）重复传参，内存拷贝开销可能盖过名字查找收益
什么时候根本不用管这个差异？
很多地方你花时间优化它，其实是在优化伪热点：
- 变量本身很大（比如一个 50MB 的 list），内存搬运成本远高于名字查找
- 代码瓶颈在
requests.get()、sqlite3.execute()或 C 扩展调用上，Python 层变量访问根本不占火焰图顶部 - 函数只调用几次，或变量每秒访问不到百次，差异在纳秒级，测量都困难
真要确认是否值得动，先用 cProfile 或 line_profiler 看 LOAD_GLOBAL 是否高频出现在耗时路径里——而不是凭直觉改。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
