装饰器叠加时执行顺序与书写顺序相反：最下方的装饰器最先执行，最上方的最后执行，即f = a(b(f))；带参装饰器需先求值得到实际装饰器再嵌套；每层应使用@wraps保持元信息，调试宜分阶段加日志。
装饰器叠加时，@decorator 的书写顺序和实际执行顺序相反
写在最上面的装饰器，最先被应用（即最晚执行），而写在最下面的，最先执行。这不是 Python 的“反直觉”，而是语法糖展开后的自然结果：@a\n@b\ndef f(): ... 等价于 f = a(b(f)) —— 从内到外套用函数。
常见错误现象：以为 @log 写在最上就最先打印日志，结果发现它反而在最里层执行，甚至没看到日志就抛出了异常。
- 执行顺序是：最下层装饰器 → 中间层 → 最上层（即包裹顺序的逆序）
- 返回值传递方向是：原函数 → 最下层装饰器 → … → 最上层装饰器 → 调用者
- 若某层装饰器没调用
func(*args, **kwargs)，后续所有上层逻辑都会被跳过
带参数的装饰器叠加时，先求值再套用
@retry(max_attempts=3) 这类装饰器本身不是装饰器，而是「返回装饰器的函数」。叠加时，Python 先执行 retry(max_attempts=3) 得到真正的装饰器，再参与 a(b(f)) 式嵌套。
容易踩的坑：在参数函数里做耗时操作（比如读配置、连数据库），会导致每次导入模块时就执行，而不是等到函数被调用。
立即学习“Python免费学习笔记（深入）”；
- 确保参数化装饰器的外层函数（如
retry()）只做必要初始化，不触发业务逻辑 - 内层闭包（真正返回的装饰器）才应包含运行时逻辑（如重试判断）
- 调试时可打印每层装饰器的定义时机，区分「定义期」和「调用期」
装饰器中 functools.wraps 只影响最外层函数元信息
叠加三层装饰器后，若只有最外层用了 @wraps(func)，那么 help()、__name__ 等只还原到被装饰的原函数；中间层若没用 wraps，其包装函数的 __doc__ 或 __module__ 会暴露出来，导致调试困难。
典型表现：inspect.signature(f) 拿不到原函数参数，或 IDE 提示参数为 *args, **kwargs。
- 每一层装饰器内部，只要返回了新函数，就应使用
@wraps(original_func) - 如果某层装饰器做了参数改写（如注入
db_session），需配合signature手动更新，仅靠wraps不够 - 用
help(f)快速验证：正确叠加后应显示原函数的文档和签名
调试装饰器执行流的实用方法
不要靠猜，直接在各层装饰器的入口和出口加日志（注意别污染生产环境）。关键是区分「装饰时」和「调用时」两个阶段。
一个可靠示例：
def trace(name):
def decorator(func):
print(f"[装饰阶段] {name} 正在包装 {func.__name__}")
@wraps(func)
def wrapper(*args, **kwargs):
print(f"[调用阶段] → 进入 {name}.{func.__name__}")
result = func(*args, **kwargs)
print(f"[调用阶段] ← 退出 {name}.{func.__name__}")
return result
return wrapper
return decorator
@trace("outer")
@trace("inner")
def say():
return "done"
运行后输出顺序清晰可见：先打印两行「装饰阶段」，调用 say() 时才按 inner → outer 执行「调用阶段」。
复杂点在于，有些装饰器（如 @lru_cache）在装饰阶段就做了不可逆初始化，叠加时顺序错可能导致缓存键计算逻辑被覆盖——这种必须严格按语义分层，不能只看执行顺序。
