装饰器本质是函数替换，定义时（def执行完）立即运行，非调用时；带参装饰器需三层结构；类装饰器适合需状态隔离或扩展的场景。
@decorator 的本质是函数替换，不是语法糖包装
装饰器执行时机：定义时还是调用时？
装饰器在函数 def 语句执行完毕后立即运行，也就是「定义时」触发，不是第一次调用时。这意味着：
@log_time
def fetch_data():
return requests.get("https://api.example.com")等价于fetch_data = log_time(fetch_data)，此时 log_time 函数体已执行一次（返回闭包），而 fetch_data 已被替换成新对象。
常见误判：以为加了 @cache 就自动缓存所有调用 —— 实际上如果 cache 装饰器没做延迟初始化，它可能在模块导入时就尝试连接 Redis，导致启动失败。
- 装饰器函数本身在模块加载时运行（除非用
if False:或动态 import 包裹） - 被装饰函数的「原逻辑」只在显式调用时执行
-
functools.wraps修正是为了保留__name__、__doc__等元信息，不修正会导致help()显示闭包函数名
带参数的装饰器为什么必须三层？
因为 Python 要求 @ 后面必须是可调用对象，且该对象接收被装饰函数作为唯一参数。所以 @retry(max_times=3) 这种写法中，retry 本身不能直接接收 max_times —— 它得先返回一个「真正」的装饰器。
结构强制为：
def retry(max_times=3):
def decorator(func):
def wrapper(*args, **kwargs):
for i in range(max_times):
try:
return func(*args, **kwargs)
except Exception:
if i == max_times - 1:
raise
return None
return wrapper
return decorator注意：retry(3) 返回的是 decorator，再由它接收 func；少一层就会报 TypeError: 'int' object is not callable。
- 第一层（
retry）处理配置参数 - 第二层（
decorator）接收函数对象 - 第三层（
wrapper）处理每次调用逻辑 - 如果漏掉某一层，错误通常出现在导入阶段，而不是运行时
类装饰器比函数装饰器更适合什么场景？
当需要维护状态、复用逻辑或支持多种行为切换时，类更清晰。比如实现一个可统计调用次数并限制频率的装饰器：
class RateLimiter:
def __init__(self, max_calls=5, window=60):
self.max_calls = max_calls
self.window = window
self.calls = []
def __call__(self, func):
def wrapper(*args, **kwargs):
now = time.time()
self.calls = [t for t in self.calls if now - t < self.window]
if len(self.calls) >= self.max_calls:
raise RuntimeError("Rate limit exceeded")
self.calls.append(now)
return func(*args, **kwargs)
return wrapper
关键差异：__init__ 可接收配置，__call__ 承担装饰器职责，实例属性天然隔离不同被装饰函数的状态。
立即学习“Python免费学习笔记（深入）”；
- 函数装饰器共享外层闭包变量，多个函数共用同一份
cache = {}，容易串数据 - 类装饰器每个实例独立，
@RateLimiter(10, 30)和@RateLimiter(3, 5)互不影响 - 类方法可被重写或扩展，比如增加
.reset()接口供测试用
装饰器调试中最容易忽略的陷阱
装饰器链中出错时，堆栈会跳过中间 wrapper，直接指向最内层函数 —— 但实际问题可能出在某个 wrapper 的参数处理或异常捕获逻辑里。
例如：
@validate_input
@cache_result
def process(x: str) -> int:
return len(x)若 x 是 None，validate_input 应该提前拦截，但如果它没做类型检查或静默吞了异常，错误会下泄到 cache_result，最终报 TypeError: unhashable type: 'NoneType'，看起来像缓存层的问题。
- 在每个 wrapper 开头加
print(f"[{func.__name__}] args: {args}")是最快定位入口方式 - 避免在 wrapper 中用
except:全局捕获，至少记录traceback.format_exc() -
inspect.signature(func)在装饰后可能失效，需在 wrapper 内用inspect.signature(wrapper)或提前保存
装饰器不是魔法，它是明确的函数赋值 + 闭包组合。真正难的从来不是写出来，而是想清楚「谁在什么时候持有哪个引用」。
