必须在装饰器内部用@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
类装饰器和函数装饰器的写法差异在哪？
类装饰器本质是实现了 __call__ 的类，而函数装饰器是返回函数的函数。两者都能扩展行为，但初始化时机、状态保持方式完全不同。
如果你需要在装饰时保存状态（比如计数、缓存、配置），类装饰器更直观；如果只是做日志、权限检查这类无状态操作，函数装饰器更轻量。
立即学习“Python免费学习笔记（深入）”；
- 类装饰器的
__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的进入/退出顺序 - 避免在装饰器里做耗时操作（如网络请求），除非你确认它总该被执行——嵌套越深，越容易误伤性能
真正麻烦的不是语法，而是当装饰器开始互相依赖状态、共享变量，或者在异步上下文里混用同步装饰器时，问题才真正浮现。
