必须在装饰器内部用@functools.wraps(func)修饰内层wrapper函数,它会将原函数的__name__、__doc__、__annotations__等元数据复制过去,从而确保help()、__name__等正确显示原始信息。

装饰器函数怎么写才不会丢失原函数的元信息?
直接用 @decorator 包裹函数后,help() 或 func.__name__ 常常显示的是装饰器内部的包装函数名,而不是原始函数名——这是最常见也最容易被忽略的问题。
根本原因是没调用 functools.wraps。它会把原函数的 __name__、__doc__、__annotations__ 等属性复制到包装函数上。
- 必须在装饰器内部用
@functools.wraps(func)修饰内层包装函数 - 别漏掉
import functools - 如果装饰器带参数(比如
@log(level='DEBUG')),wraps要套在最内层函数上,不是中间那层
import functools
<p>def log_calls(func):
@functools.wraps(func) # 关键:这一行不能少
def wrapper(*args, *<em>kwargs):
print(f"Calling {func.<strong>name</strong>}")
return func(</em>args, **kwargs)
return wrapper
</p>
类装饰器和函数装饰器的写法差异在哪?
类装饰器本质是实现了 __call__ 的类,而函数装饰器是返回函数的函数。两者都能扩展行为,但初始化时机、状态保持方式完全不同。
如果你需要在装饰时保存状态(比如计数、缓存、配置),类装饰器更直观;如果只是做日志、权限检查这类无状态操作,函数装饰器更轻量。
- 类装饰器的
__init__接收被装饰对象(函数或类),__call__才执行实际逻辑 - 装饰类时,类装饰器的
__call__会在实例化目标类时触发,不是定义时 - 函数装饰器不能直接用于类方法而不加括号——
@cache可以,但@cache()才能传参
class CountCalls:
def __init__(self, func):
self.func = func
self.count = 0
functools.update_wrapper(self, func) # 注意:这里用 update_wrapper 替代 wraps
<pre class="brush:php;toolbar:false;">def __call__(self, *args, **kwargs):
self.count += 1
print(f"{self.func.__name__} called {self.count} times")
return self.func(*args, **kwargs)
给类本身加装饰器时,为什么 __init__ 不生效?
装饰一个类(如 @add_timestamp)并不会自动修改它的 __init__ 方法,而是替换整个类对象。所以你得在装饰器里显式重写或包装 __init__,否则新增逻辑不会进入实例化流程。
典型错误是只改了类的属性或加了静态方法,却忘了干预构造过程——结果看起来“装饰成功”,但新职责根本没在创建实例时触发。
- 装饰类时,返回的新类必须继承原类,或至少保留其
__dict__结构 - 如果要拦截
__init__,要在新类中重定义它,并在其中调用super().__init__() - 避免直接覆盖原类的
__init__属性,而应通过types.FunctionType动态构造,否则isinstance可能失效
def add_init_log(cls):
orig_init = cls.__init__
def new_init(self, *args, **kwargs):
print(f"Creating instance of {cls.__name__}")
orig_init(self, *args, **kwargs)
cls.__init__ = new_init
return cls
装饰器嵌套顺序为什么影响最终行为?
多个装饰器从下往上执行(即离函数定义最近的先运行),这个顺序直接决定各层包装函数的嵌套层级。一旦某层抛异常或提前返回,外层就收不到调用。
比如 @cache 和 @auth 套在一起,如果 @auth 放在下面,它会在缓存逻辑之前检查权限;反过来,就可能缓存了未授权的响应。
- 写装饰器时,明确每层的职责边界:谁该处理异常?谁该修改参数?谁该短路返回?
- 调试时用
print或日志打点,观察各层wrapper的进入/退出顺序 - 避免在装饰器里做耗时操作(如网络请求),除非你确认它总该被执行——嵌套越深,越容易误伤性能
真正麻烦的不是语法,而是当装饰器开始互相依赖状态、共享变量,或者在异步上下文里混用同步装饰器时,问题才真正浮现。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











