一、从一个计数器开始
许多开发者在学习Python作用域时，都曾被下面这段代码困扰：
def make_counter():
count = 0
def counter():
count += 1 # 这里会报错
return count
return counter
c = make_counter()
print(c()) # UnboundLocalError: local variable 'count' referenced before assignment
这并非Python的bug，而是其作用域规则在发挥作用。理解count += 1这行代码为何报错，是掌握闭包机制的关键一步。
要彻底弄懂这个问题，我们需要深入理解Python的作用域规则与闭包的工作原理。
二、LEGB 规则：名字查找的顺序
在Python中，变量名的查找遵循固定的LEGB法则：
- L（Local）：当前函数内部定义的局部变量
- E（Enclosing）：外层嵌套函数中的变量
- G（Global）：模块级全局变量
- B（Built-in）：Python内置名称，如
len、print
通过一段代码可以直观验证这个顺序：
x = "global" # G 层
def outer():
x = "enclosing" # E 层
def inner():
x = "local" # L 层
print(x) # -> local（找到即停止）
inner()
outer()
每一层都可以定义与上层同名的变量，它们相互独立。Python的这种设计源于其名字查找发生在运行时——解释器执行到某行代码时，才会在对应的作用域中寻找变量。
LEGB规则可以形象地理解为：
查找过程如同从圆心向外扩散，由内而外，找到即止。
三、global关键字：打破 E 层
回到开头报错的计数器。问题在于count += 1这行代码，它等价于：
count = count + 1
Python解释器看到等号左侧出现count，会立即将其判定为当前作用域（L层）的局部变量。但count实际定义在make_counter()的作用域（E层），而非counter()的局部作用域。Python不允许在E层为L层创建同名变量，因此触发UnboundLocalError。
一个直接的解决方案是将count提升至全局作用域：
count = 0
def make_counter():
global count # 声明访问全局变量 count
count += 1
return count
print(make_counter()) # 1
print(make_counter()) # 2
但global存在一个致命缺陷：它使count成为模块级全局变量。这意味着多个make_counter()实例将共享同一个count，破坏了计数器之间的状态隔离。
四、nonlocal关键字：访问 E 层变量
nonlocal可视为global的近亲，但作用域完全不同。它允许在L层函数中修改E层（嵌套外层）的变量：
def make_counter():
count = 0
def counter():
nonlocal count # 声明：对 count 的赋值作用于外层变量
count += 1
return count
return counter
c = make_counter()
print(c()) # 1
print(c()) # 2
print(c()) # 3
关键在于，nonlocal不会在L层创建新变量，也不涉及G层——它直接作用于最近一层外层函数的变量。
以下是global与nonlocal的对比：
| 关键字 | 作用层 | 行为 |
|---|---|---|
global | 模块级 G 层 | 读写全局变量，多个函数共享 |
nonlocal | 嵌套外层 E 层 | 读写外层函数变量，多个闭包独立 |
五、闭包的完整执行流程
理解nonlocal后，我们完整分析闭包的执行流程。先看未添加关键字的原始代码：
def make_counter():
count = 0 # <- E 层变量
def counter():
print("count 当前值:", count) # 读 E 层变量 - 正常
return count # 读 E 层变量 - 正常
return counter
可见，单纯的读取操作（不加nonlocal）不会报错——Python允许读取外层变量。只有写操作（如count = something或count += something）才会触发UnboundLocalError，因为等号左侧让Python误认为要创建新的L层变量。
当Python看到nonlocal count声明时，在编译期（生成字节码阶段）就已记录此信息：
import dis
def make_counter():
count = 0
def counter():
nonlocal count
count += 1
return count
return counter
# counter 函数的字节码
dis.dis(counter := make_counter())
关键字节码如下：
5 2 LOAD_GLOBAL 0 (count)
4 LOAD_CONST 1 (1)
6 BINARY_OP 0 (+)
8 STORE_FAST 0 (count)
10 LOAD_FAST 0 (count)
12 RETURN_VALUE
注意LOAD_GLOBAL 0 (count)这行，这是nonlocal的实现方式。若无nonlocal声明，此行会变为LOAD_FAST（试图读取L层变量），随后的STORE_FAST将因变量未定义而触发UnboundLocalError。
六、闭包变量的生命周期
闭包有一个关键特性：闭包变量的生命周期与闭包函数本身相同。
def make_multiplier(factor):
# factor 绑定在 make_multiplier 的局部作用域
def multiply(value):
return value * factor
return multiply
doubler = make_multiplier(2)
# make_multiplier() 已执行完毕
# 但 doubler 仍持有 factor=2
print(doubler(5)) # 10
print(doubler(100)) # 200
factor原本是make_multiplier()的局部变量。通常函数执行完毕后，其局部变量会被销毁。但doubler仍在引用它，因此Python的垃圾回收机制检测到factor有外部引用，将其保留并通过cell对象包装后存入doubler.__closure__属性。
这就是为何能通过doubler.__closure__[0].cell_contents读取到2——cell对象是闭包变量在内存中的载体。
>>> doubler.__closure__ (| ,) >>> doubler.__closure__[0].cell_contents 2 |
再看一个复杂示例，验证多个闭包如何共享同一外层变量：
def processor(initial=0):
total = initial
def add(x):
nonlocal total
total += x
return total
def subtract(x):
nonlocal total
total -= x
return total
return add, subtract
add, subtract = processor(100)
print(add(30)) # 130，total = 100 + 30
print(subtract(20)) # 110，total = 130 - 20
print(add(10)) # 120，total = 110 + 10
add和subtract这两个闭包函数指向同一cell对象。因此，修改total对两个函数均生效。这种“共享状态”特性在事件处理器、回调函数等场景中非常实用。
七、闭包的典型应用场景
场景一：函数工厂（最常见用法）
根据不同参数动态生成特定功能函数：
def power_factory(exp):
def power(base):
return base ** exp
return power
square = power_factory(2)
cube = power_factory(3)
print(square(5)) # 25
print(cube(5)) # 125
exp参数被捕获在各自闭包中，square和cube拥有独立的exp值，互不干扰。相比为每种指数编写独立函数，函数工厂方式更灵活、优雅。
场景二：带记忆的递归函数
def memoized_fibonacci():
cache = {} # E 层变量
def fib(n):
if n in cache:
return cache[n]
if n <= 1:
result = n
else:
result = fib(n-1) + fib(n-2)
cache[n] = result
return result
return fib
fib = memoized_fibonacci()
print(fib(100)) # 354224848179261915075
print(fib(200)) # 280571172992510140037611908417314019
cache字典在闭包中持久化，每次递归调用都能访问同一缓存。这巧妙避免了普通递归中子问题重复计算的开销。
场景三：装饰器（闭包的直接应用）
装饰器本质上是闭包的经典应用：
import functools
import time
def timing_decorator(fn):
@functools.wraps(fn)
def wrapper(*args, **kwargs):
# fn 和 elapsed_time 均为闭包变量
start = time.perf_counter()
result = fn(*args, **kwargs)
elapsed = time.perf_counter() - start
print(f"{fn.__name__} 耗时 {elapsed:.4f}s")
return result
return wrapper
wrapper函数捕获了两个自由变量：fn（被装饰函数）和计时变量。timing_decorator返回的wrapper闭包中包含对被装饰函数的引用。调用被装饰后的函数时，实际执行的是此wrapper。
八、闭包的常见错误：迟绑定
这是闭包概念中最隐蔽的陷阱。当闭包在循环中创建时，所有闭包实例捕获的是同一变量，而该变量的值以闭包被调用时的值为准，而非创建时的值：
def create_multipliers():
multipliers = []
for i in range(5):
multipliers.append(lambda x: x * i) # i 是自由变量
return multipliers
fns = create_multipliers()
# 全部返回 4*4=16，而非 0*4, 1*4, 2*4, 3*4, 4*4
print([fn(4) for fn in fns]) # [16, 16, 16, 16, 16]
问题在于循环结束时i = 4，所有闭包引用同一i。调用时获取的都是最终的4，结果均为4 * 4 = 16。
解决方案：利用默认参数在闭包创建时立即捕获当前值：
def create_multipliers_fixed():
multipliers = []
for i in range(5):
multipliers.append(lambda x, i=i: x * i) # i=i 将当前值绑定为默认参数
return multipliers
fns = create_multipliers_fixed()
print([fn(4) for fn in fns]) # [0, 4, 8, 12, 16]
在lambda x, i=i: ...中，右侧i是自由变量，定义时取值为当前循环变量；左侧i是默认参数，绑定到lambda的局部作用域。每次循环迭代，当前i值被“冻结”进默认参数，后续循环变量变化不影响已绑定的值。
使用functools.partial也能达到相同效果：
import functools
def create_multipliers_partial():
multipliers = []
for i in range(5):
multipliers.append(functools.partial(lambda x, i: x * i, i=i))
return multipliers
九、__closure__与自由变量的深度解析
可通过__code__.co_freevars属性直接查看函数捕获的自由变量：
def outer(x):
def inner(y):
# z 从更外层捕获
def deeper(z):
return x + y + z
return deeper
return inner
# 查看各层函数的自由变量
outer_fn = outer(10)
inner_fn = outer_fn(20)
deeper_fn = inner_fn(30)
>>> outer_fn.__code__.co_freevars
('x',)
>>> inner_fn.__code__.co_freevars
('x', 'y')
>>> deeper_fn.__code__.co_freevars
('x', 'y', 'z')
# __closure__ 顺序与 co_freevars 一一对应
>>> deeper_fn.__closure__
(, , | )
>>> deeper_fn.__closure__[0].cell_contents, \
deeper_fn.__closure__[1].cell_contents, \
deeper_fn.__closure__[2].cell_contents
(10, 20, 30)
| | |
co_freevars是字节码层面的元信息，告知解释器哪些名称是自由变量；__closure__则是这些自由变量对应的cell对象序列，两者顺序完全一致。
十、知识点总结
