Python装饰器执行顺序与functools.wraps解析

1. Python装饰器执行顺序的本质解析

"距离被修饰函数越近的装饰器，越先执行"——这个看似简单的规则背后，隐藏着Python解释器处理装饰器的核心机制。让我们从一个具体例子开始：

python复制@decorator1
@decorator2
def my_function():
    pass

上述代码的实际执行等价于：

python复制def my_function():
    pass
my_function = decorator1(decorator2(my_function))

这个语法糖的展开过程揭示了三个关键事实：

1. 从下往上：最靠近函数的装饰器（decorator2）最先被应用
2. 嵌套包装：外层装饰器（decorator1）接收的是内层装饰器处理后的函数
3. 不可逆顺序：这种嵌套结构决定了装饰器的执行顺序与调用顺序相反

2. 装饰器元数据丢失问题与functools.wraps的救赎

当我们检查被装饰后的函数时，会发现一个恼人的现象：

python复制def simple_decorator(func):
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

@simple_decorator
def greet():
    """返回问候语"""
    return "Hello!"

print(greet.__name__)  # 输出：wrapper
print(greet.__doc__)   # 输出：None

这种元数据丢失会导致：

• 调试困难（所有被装饰函数都显示为"wrapper"）
• 文档工具失效（如Sphinx无法获取原始docstring）
• 类型检查器报错（函数签名被掩盖）

2.1 functools.wraps的工作原理

functools.wraps通过以下方式解决这个问题：

python复制from functools import wraps

def proper_decorator(func):
    @wraps(func)  # 关键在此
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

其内部实现主要做了三件事：

1. 复制__module__、__name__等特殊属性
2. 更新包装函数的__dict__字典
3. 保留原始函数的注解信息（Python 3+）

3. 装饰器堆叠时的执行顺序陷阱

当多个装饰器叠加使用时，执行顺序会变得复杂。考虑以下案例：

python复制@decorator_A
@decorator_B
@decorator_C
def target_function():
    pass

实际执行流程相当于：

python复制temp1 = decorator_C(target_function)
temp2 = decorator_B(temp1)
final_result = decorator_A(temp2)

3.1 实战中的顺序问题排查

我曾在一个Web项目中遇到这样的问题：

python复制@cache_response(expire=300)
@require_login
@validate_params
def api_handler(request):
    # 处理逻辑

调试时发现：

1. 参数验证总是最后执行（导致缓存了非法请求）
2. 登录检查有时被跳过（因为缓存了未登录响应）

解决方案是调整装饰器顺序：

python复制@validate_params
@require_login
@cache_response(expire=300)
def api_handler(request):
    # 处理逻辑

4. 高级装饰器模式与元数据保护

对于需要保留类型提示的装饰器，Python 3.10+提供了更完善的解决方