局部变量访问快是因为通过栈帧的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 disdef f(): x = 1 return x + 1
dis.dis(f)
立即学习“Python免费学习笔记（深入）”；
输出中你会看到：
2 0 LOAD_CONST 1 (1)
2 STORE_FAST 0 (x)
4 LOAD_FAST 0 (x)
6 LOAD_CONST 1 (1)
8 BINARY_ADD
10 RETURN_VALUE
注意 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
快：提升到局部作用域
def calc():
LIMIT = 1000000
total = 0
for i in range(LIMIT):
total += i * 2
return total
这不是因为“局部变量本身更快”，而是因为循环体内的每次 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 把“确定存在且生命周期明确”的变量，交由最轻量的内存访问机制处理。但这个优势，很容易被一次不经意的属性访问、闭包捕获或动态作用域操作抹平。
