局部变量访问快是因为通过栈帧的fastlocals数组直接按索引取值，无需字典哈希查找；LOAD_FAST指令对应编译期确定的偏移量，而全局、自由或动态变量需LOAD_GLOBAL/LOAD_DEREF或字典查找，开销更大。
局部变量查找走的是栈帧的快速索引，不是字典查找
Python 解释器在执行函数时会为它创建一个独立的栈帧（frame），其中局部变量不存于 __dict__ 或全局命名空间字典里，而是直接分配在栈帧对象的 f_locals 数组（实际是 C 层的 fastlocals）中。访问时通过固定偏移量直接取值，跳过了哈希计算和字典键比对。
这和全局变量或自由变量形成鲜明对比：全局变量要查 globals() 字典，自由变量（闭包中的外层变量）要查 cell 对象再间接取值，都涉及至少一次哈希查找。
-
LOAD_FAST指令用于局部变量，底层是 C 数组下标访问 -
LOAD_GLOBAL指令需调用PyDict_GetItem，有哈希 + 键比较开销 - 哪怕只多一层作用域（比如嵌套函数里读外层变量），也触发
LOAD_DEREF，性能明显下降
使用 dis 能直观看到指令差异
你可以用 dis.dis() 查看字节码，确认变量是否走 LOAD_FAST：
import dis <p>def f(): x = 1 return x + 1</p><p>dis.dis(f)</p><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/00968c3c2c15" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">Python免费学习笔记（深入）</a>”；</p><h1>输出中你会看到：</h1><h1>2 0 LOAD_CONST 1 (1)</h1><h1>2 STORE_FAST 0 (x)</h1><h1>4 LOAD_FAST 0 (x)</h1><h1>6 LOAD_CONST 1 (1)</h1><h1>8 BINARY_ADD</h1><h1>10 RETURN_VALUE</h1>
注意 STORE_FAST 和 LOAD_FAST 的操作数是数字索引（如 0），不是变量名字符串 —— 这就是编译期就确定好的位置。
- 如果变量被
exec、eval或locals()动态读取，Python 会禁用fastlocals，退化为字典查找 -
nonlocal和global声明会让变量退出 fastlocal 范围，改用LOAD_DEREF或LOAD_GLOBAL
循环内频繁访问变量，局部化收益最明显
在密集计算或长循环中，局部变量的访问优势会被放大。比如下面两段代码的实际耗时可能差 15%～25%：
# 慢：全局查找
LIMIT = 1000000
total = 0
for i in range(LIMIT):
total += i * 2
<h1>快：提升到局部作用域</h1><p>def calc():
LIMIT = 1000000
total = 0
for i in range(LIMIT):
total += i * 2
return total</p>这不是因为“局部变量本身更快”，而是因为循环体内的每次 i、LIMIT、total 访问都省掉了字典操作。
- 即使只是把常量赋给局部变量（如
func = some_module.some_func），再在循环里调用，也能减少属性查找开销 - 但别过度优化：如果逻辑清晰性受损，或变量生命周期本就不该局限在函数内，强行局部化反而增加维护成本
真正拖慢速度的往往不是变量访问，而是隐式作用域泄漏
很多人以为“把变量放函数里就自动快了”，却忽略了更关键的陷阱：比如在类方法中反复访问 self.xxx，这本质是属性查找（LOAD_ATTR），比局部变量慢得多；又比如在循环里写 for x in obj.items() 却没把 obj.items 提前绑定为局部变量。
-
self.attr→ 触发__getattribute__链，可能含描述符、property 等开销 -
module.func→ 每次都要查模块字典 + 属性缓存未命中时更慢 - 真正该优先局部化的，是那些在循环/递归高频路径上被反复读写的名称
局部变量快的本质，是 Python 把“确定存在且生命周期明确”的变量，交由最轻量的内存访问机制处理。但这个优势，很容易被一次不经意的属性访问、闭包捕获或动态作用域操作抹平。
