Python装饰器本质是闭包与高阶函数的自然产物，是接收函数并返回新函数的“函数工厂”；@语法糖等价于手动赋值，带参装饰器需三层嵌套，须用functools.wraps保留元信息，类装饰器适合管理状态但需实现__call__。
Python 装饰器不是语法糖的“魔法”，而是函数式编程中 闭包 + 高阶函数 的自然产物；只要理解 def 语句执行时创建函数对象、函数可赋值/传参/返回的本质，装饰器就不再黑盒。
装饰器本质是「函数工厂」：@syntax 只是语法糖
所谓 @log_time，等价于：
def my_func():
pass
my_func = log_time(my_func)这意味着：
-
log_time必须是可调用对象，且返回值也必须是可调用对象（通常是函数） - 被装饰函数的
__name__、__doc__等元信息默认会丢失——因为实际运行的是包装后的函数 - 如果
log_time接收参数（如@log_time(level='DEBUG')），它必须再套一层函数：外层接收参数，返回内层装饰器
带参数的装饰器必须三层嵌套，缺一不可
常见错误是写成两层，导致解释器报错 TypeError: 'function' object is not callable 或直接跳过装饰逻辑。正确结构：
立即学习“Python免费学习笔记（深入）”；
def retry(max_attempts=3, delay=1):
def decorator(func): # 第二层：真正的装饰器
def wrapper(*args, **kwargs):
for i in range(max_attempts):
try:
return func(*args, **kwargs)
except Exception:
if i == max_attempts - 1:
raise
time.sleep(delay)
return wrapper
return decorator # 第一层返回装饰器关键点：
- 最外层
retry()接收配置参数，返回第二层decorator - 第二层
decorator接收被装饰函数，返回第三层wrapper - 不能省略任意一层，否则
@retry()无法解析为合法装饰器调用
用 functools.wraps 修复元信息丢失问题
不加 @wraps(func)，help(my_decorated_func) 显示的是 wrapper 的签名和文档，而非原函数。修复只需一行：
from functools import wraps
<p>def log_call(func):
@wraps(func) # ← 这行必须有，且必须在 wrapper 定义后立即使用
def wrapper(*args, *<em>kwargs):
print(f"Calling {func.<strong>name</strong>}")
return func(</em>args, **kwargs)
return wrapper它等价于手动复制：wrapper.__name__ = func.__name__、wrapper.__doc__ = func.__doc__ 等。漏掉这行，调试和 IDE 提示会严重失真。
类装饰器比函数装饰器更易管理状态，但要注意 __call__ 的细节
当需要在多次调用间共享状态（如计数、缓存、连接池），类装饰器更直观：
class CountCalls:
def __init__(self, func):
self.func = func
self.count = 0
wraps(func)(self) # 同样要保留原函数元信息
<pre class='brush:python;toolbar:false;'>def __call__(self, *args, **kwargs):
self.count += 1
return self.func(*args, **kwargs)注意：
- 类实例必须实现
__call__才能被调用；否则@CountCalls会报TypeError: 'CountCalls' object is not callable -
wraps(func)(self)是把原函数元信息绑定到实例上，不是绑定到__call__方法 - 类装饰器无法直接支持带参数的语法（如
@CountCalls(threshold=10)），需额外加一层工厂类或改用函数式三层结构
真正卡住人的从来不是语法，而是没想清楚「谁在什么时候被调用」：装饰器定义时执行？装饰时执行？还是被装饰函数调用时执行？把这三阶段拆开验证，比死记模板有效得多。
