装饰器本质是函数式组合的语法糖,即@decorator等价于func = decorator(func),其核心是返回兼容原函数签名的新函数,并需用@wraps保留元信息以支持类型检查与IDE推导。
Python 装饰器不是魔法,它只是把 func = decorator(func) 这种显式函数包装,用 @decorator 语法糖重写了一遍。真正起作用的,是装饰器返回的新函数——这个新函数通常内部调用原函数,并在其前后插入逻辑。这和函数式编程里的组合(compose(f, g) 表示先 g 再 f)在语义上完全一致。
关键在于:所有装饰器都必须返回一个可调用对象,且该对象参数签名需兼容原函数(否则调用会出错)。常见错误是装饰器内部没正确传递 *args 和 **kwargs,导致被装饰函数接收不到参数。
functools.wraps(func) 包裹内层函数,避免丢失原函数的 __name__、__doc__ 等元信息@a\n@b\ndef f())等价于 f = a(b(f)),注意执行顺序是从下往上、组合方向是右到左当需要动态组合多个装饰器(比如根据配置开关日志、缓存、权限),硬写 @log @cache @auth 不够灵活。此时可自己写一个 compose 函数,把装饰器当作一元函数来组合:
def compose(*funcs):
def inner(x):
for f in reversed(funcs):
x = f(x)
return x
return inner
等价于 @timer @validate @retry
wrapped = compose(timer, validate, retry)(my_func)
注意 reversed:因为 compose(f, g) 本意是 f(g(x)),而装饰器链 @f @g 实际是 
f(g(h)),所以组合时要倒序遍历。
compose 无法串联wrapped.__name__ 可能显示 inner,务必在每个装饰器里用 @wraps
很多开发者只把 @wraps 当作让 help() 显示正确文档的补救措施,但它对静态分析工具(如 mypy、PyCharm)同样关键。没有 @wraps,装饰后的函数类型会被识别为 Any 或闭包类型,导致参数提示丢失、类型校验失效。
典型表现:my_func(123) 在 IDE 里没有参数提示,mypy 报 error: "Callable[..., Any]" has no attribute "__name__"。
@wraps(func),而不是在装饰器函数本身@retry(max_attempts=3)),@wraps 要放在最内层返回的函数上tenacity、backoff)多数已内置 @wraps,但自定义时极易遗漏当某个装饰器需要固定部分参数(比如 @cache(ttl=300)),又想把它和其他装饰器组合使用时,直接传 cache(ttl=300) 会立即执行并返回非函数对象。这时应改用 functools.partial 延迟求值:
from functools import partialcached_5min = partial(cache, ttl=300) wrapped = compose(cached_5min, validate, log)(my_func)
这比写一个专门的 cache_5min 工厂函数更轻量,也避免了闭包嵌套过深。
partial 返回的是可调用对象,满足装饰器组合链要求partial(如 partial(cache(...)(func), ...)),那已经是最终函数了lambda 相比,partial 更易读、可序列化、支持 __repr__,适合生产环境装饰器与函数式组合的边界其实很薄——只要你始终记得:装饰器是函数,返回值是函数,组合就是函数套函数。最容易被忽略的是签名一致性:哪怕逻辑再简单,漏传 *args 或忘了 @wraps,下游调用就会悄无声息地崩掉。