Python闭包与装饰器的高级陷阱

Python闭包与装饰器的高级陷阱

闭包看似简单，但实际使用中隐藏着大量陷阱。先看一个常见的问题：

def make_counters():
counters = []
for i in range(5):
def counter():
return i
counters.append(counter)
return counters

for c in make_counters():
print(c())

输出结果是4, 4, 4, 4, 4，而不是0, 1, 2, 3, 4。原因在于闭包捕获的是变量i的引用，而不是i的值。当counter被调用时，for循环已经执行完毕，i的值是4。

解决方法是利用默认参数在定义时绑定值：

def make_counters():
counters = []
for i in range(5):
def counter(i=i):
return i
counters.append(counter)
return counters

默认参数在函数定义时求值，i=i把当前值绑定到默认参数上。但这种方式有个隐患：如果有人调用counter()时传了参数，就会覆盖默认值。更安全的方式是用闭包工厂：

def make_counters():
counters = []
for i in range(5):
def make_counter(val):
def counter():
return val
return counter
counters.append(make_counter(i))
return counters

每次调用make_counter(i)都创建一个新的作用域，val被绑定到传入的值上，不再受后续循环影响。

装饰器的参数传递陷阱更隐蔽。看这个例子：

def timer(func):
import time
def wrapper(*args, **kwargs):
start = time.perf_counter()
result = func(*args, **kwargs)
print(f"{func.__name__} took {time.perf_counter() - start:.4f}s")
return result
return wrapper

@timer
def process(data, timeout=30):
pass

表面上看没问题，但wrapper的签名丢失了。inspect.signature(process)返回的是(*args, **kwargs)，而不是(data, timeout=30)。使用functools.wraps可以修复：

from functools import wraps

def timer(func):
import time
@wraps(func)
def wrapper(*args, **kwargs):
...
return wrapper

functools.wraps把原函数的__name__、__qualname__、__doc__、__dict__、__module__、__annotation__等属性复制到wrapper上。但它不修复签名，inspect.signature仍然返回错误的签名。完整的修复需要：

from functools import wraps
import inspect

def timer(func):
@wraps(func)
def wrapper(*args, **kwargs):
...
wrapper.__signature__ = inspect.signature(func)
return wrapper

带参数的装饰器需要三层嵌套：

def retry(max_attempts=3, delay=1):
def decorator(func):
@wraps(func)
def wrapper(*args, **kwargs):
for attempt in range(max_attempts):
try:
return func(*args, **kwargs)
except Exception as e:
if attempt == max_attempts - 1:
raise
time.sleep(delay)
return wrapper
return decorator

@retry(max_attempts=5, delay=2)
def fetch_data(url):
pass

@retry() # 注意：括号不能省略
def fetch_other(url):
pass

retry()必须加括号，即使使用默认参数。因为retry是一个返回装饰器的函数，不是装饰器本身。如果写成@retry而不是@retry()，Python会把retry当作装饰器调用，把被装饰函数作为max_attempts参数传进去。

一个技巧是判断第一个参数是否可调用：

def retry(func=None, max_attempts=3, delay=1):
if func is not None:
@wraps(func)
def wrapper(*args, **kwargs):
...
return wrapper
else:
def decorator(func):
@wraps(func)
def wrapper(*args, **kwargs):
...
return wrapper
return decorator

@retry
def foo(): pass # 无参数

@retry(max_attempts=5) # 有参数
def bar(): pass

这个模式的原理是：如果retry后面没有括号，Python直接把被装饰函数作为func传入；如果有括号，func为None，进入else分支返回真正的装饰器。

类装饰器的self绑定问题：

class Logger:
def __init__(self, func):
self.func = func

def __call__(self, *args, **kwargs):
print(f"Calling {self.func.__name__}")
return self.func(*args, **kwargs)

@Logger
def compute(x, y):
return x + y

compute(1, 2) # 正常

class MyClass:
@Logger
def method(self):
return 42

MyClass().method() # 会出错

method被装饰后变成了Logger的实例。当通过实例访问时，Python不会自动传入self。需要手动处理描述符协议：

class Logger:
def __init__(self, func):
self.func = func

def __call__(self, *args, **kwargs):
print(f"Calling {self.func.__name__}")
return self.func(*args, **kwargs)

def __get__(self, obj, objtype=None):
if obj is None:
return self
import functools
return functools.partial(self.__call__, obj)

通过实现__get__方法，Logger变成了描述符。当通过实例访问被装饰的方法时，__get__被调用，返回绑定好self的partial对象。

装饰器的堆叠顺序也很重要：

@log
@validate
@cache
def expensive(x):
return complex_calc(x)

等价于expensive = log(validate(cache(expensive)))。执行顺序是从下到上装饰，从上到下执行。调用expensive(x)时先执行log，再执行validate，最后执行cache。

如果装饰器之间相互依赖，顺序错误会导致灾难。比如@login_required必须在@route之后，因为@route可能改变了函数的URL路由信息。

闭包的内存泄漏是另一个常见问题：

def create_report():
large_data = load_terabytes_of_data()

def generate():
return process(large_data)

return generate

reporter = create_report()

reporter持有对large_data的引用，即使generate函数不直接使用large_data。在CPython中，闭包捕获了整个外层作用域的变量集合。__closure__属性中包含了所有被引用的自由变量：

print(reporter.__closure__)

如果large_data在generate中从未被使用，但它定义在同一个作用域中，仍然会被捕获。解决方法是在不需要时删除引用：

def create_report():
large_data = load_terabytes_of_data()
result = process(large_data)
del large_data # 提前释放

def generate():
return result

return generate

装饰器堆叠过多时的问题：

@decorator1
@decorator2
@decorator3
@decorator4
@decorator5
def deeply_decorated():
pass

调用deeply_decorated时的函数调用栈深度等于装饰器层数加一。如果每个装饰器都添加了try/except或日志，堆栈跟踪会变得极其混乱。

解决方式是使用装饰器压缩技术：

def compose(*decorators):
def deco(func):
for decorator in reversed(decorators):
func = decorator(func)
return func
return deco

@compose(decorator1, decorator2, decorator3, decorator4, decorator5)
def deeply_decorated():
pass

compose把所有装饰器合并成一个，减少了调用栈深度。

更严重的是循环导入问题。当装饰器定义在另一个模块中，而被装饰函数所在的模块也被装饰器模块导入时：

# decorators.py
from .utils import helper

def log(func):
@wraps(func)
def wrapper(*args, **kwargs):
helper() # 使用utils的功能
return func(*args, **kwargs)
return wrapper

# utils.py
from .decorators import log

@log
def helper():
pass

导入utils时，Python尝试导入decorators；导入decorators时，Python又尝试导入utils。此时utils尚未完全加载，@log装饰器执行时导致ImportError。

解决方式是延迟导入：

# decorators.py
def log(func):
@wraps(func)
def wrapper(*args, **kwargs):
from .utils import helper # 延迟导入
helper()
return func(*args, **kwargs)
return wrapper

或者使用forward reference模式，把装饰器移到独立的模块中，让装饰器模块只依赖基础工具，不依赖业务模块。

这些陷阱在真实项目中几乎都会遇到。理解闭包和装饰器的底层机制，是绕过这些陷阱的关键。