装饰器本质是函数调用链的包装器，@decorator 等价于 func = decorator(func)，需确保每层 return 可调用对象；带参装饰器需三层嵌套；@property 等内置装饰器基于描述符协议，非普通闭包。
装饰器本质是函数调用链的“包装器”
Python 装饰器不是语法糖，而是明确的函数调用：@decorator 等价于 func = decorator(func)。它不改变原函数对象，只是把原函数作为参数传给装饰器，返回一个新可调用对象（通常是闭包或类实例）。
常见错误现象：TypeError: 'NoneType' object is not callable —— 多半因为装饰器内部没写 return，导致返回 None；或者漏了内层函数的 return，导致被装饰函数永远返回 None。
- 必须确保装饰器函数本身有
return，且返回的是可调用对象（比如内层函数） - 被装饰函数的返回值要显式从内层函数中
return出来，否则调用结果丢失 - 如果想保留原函数的
__name__、__doc__，得用@functools.wraps(func)修饰内层函数
带参数的装饰器需要三层嵌套
当你看到 @retry(max_attempts=3) 这种写法，说明这不是直接装饰，而是“装饰器工厂”：外层函数接收装饰器参数，返回真正的装饰器（第二层），再由它接收被装饰函数（第三层）。
使用场景：统一配置重试策略、日志级别、缓存 TTL 等。参数差异直接影响行为逻辑，比如 cache_ttl=60 和 cache_ttl=None 应触发完全不同的缓存路径。
立即学习“Python免费学习笔记（深入）”；
- 第一层（工厂）：接收装饰器参数，
return第二层函数 - 第二层（装饰器）：接收被装饰函数，
return第三层函数 - 第三层（包装器）：实际执行逻辑，通常含
*args, **kwargs并调用原函数 - 漏掉任意一层
return，都会导致TypeError或静默失效
@property 和 @staticmethod 是内置装饰器，但行为不可覆盖
@property 不是普通装饰器——它返回的是 property 对象，该对象实现了描述符协议（__get__ / __set__），所以能控制属性访问。同理，@staticmethod 和 @classmethod 返回的是各自类型的描述符对象，不是闭包。
性能影响：每次访问 @property 方法都会触发函数调用，无法像普通属性那样 O(1) 访问；若内部有 IO 或复杂计算，容易成为性能瓶颈。
- 不要试图用自定义装饰器“模拟”
@property行为，除非你手动实现描述符协议 -
@staticmethod不接收self或cls，但它仍受类继承链影响——子类覆写同名方法时，@staticmethod不会自动绑定，这点和普通方法不同 - 调试时注意：IDE 或
help()显示的签名可能仍是原始函数，而非包装后行为
装饰器顺序影响执行流，越靠近函数的越先执行
多个装饰器如 @a、@b、@c 自上而下书写，等价于 c(b(a(func)))。也就是说，最下方的装饰器最先被应用，它的返回值成为下一个装饰器的输入。
容易踩的坑：以为顺序是执行顺序。实际是“包装顺序”，而运行时是反向调用——最外层装饰器的包装器最先被调用，最内层的最后执行（但也最先返回）。
- 日志装饰器放在最外层（
@log），能记录整个调用链；权限校验放中间，避免在无权时还执行耗时预处理 - 如果两个装饰器都修改了
__dict__或动态添加属性，后应用的会覆盖先应用的 - 调试时建议加简单 print，比如
print("enter a")/print("exit a")，观察进出栈顺序
装饰器最难缠的地方不在写法，而在调试时看不到真实调用栈——traceback 里常只显示包装器那一层。用 functools.wraps 只能修复元信息，修不了栈帧。真出问题，得靠断点打在内层函数里，而不是依赖报错位置。
