装饰器本质是基于闭包的语法糖，通过多层嵌套函数实现参数化配置，类装饰器适用于需维护状态的场景，装饰器链按从下往上顺序包装、从上往下执行。

装饰器本质是闭包，但不止于闭包

装饰器在语法上是 @ 开头的语法糖，但它的底层依赖闭包机制：外层函数接收被装饰函数作为参数，内层函数保留对外层作用域中该函数的引用，并在适当时候调用它。关键点在于——闭包让内层函数“记住”了原始函数和附加逻辑，装饰器则把这种记忆能力标准化、可复用化。

写一个真正可用的带参装饰器

很多教程只讲无参装饰器，但实际项目中常需传入配置（如重试次数、超时阈值）。核心是多嵌套一层函数：

• 最外层接收装饰器参数（如 max_retries=3），返回真正的装饰器
• 中间层接收被装饰函数，返回包装后的函数
• 最内层是实际执行逻辑，可访问所有外层变量（闭包捕获）

注意：必须用 functools.wraps(func) 修复元信息，否则被装饰函数的 __name__、__doc__ 会变成内层函数名，影响调试和文档生成。

类装饰器：当逻辑变复杂时的自然选择

当需要维护状态（如调用计数、缓存、锁管理）或组合多个行为时，类比函数更清晰。类只要实现 __call__ 方法，实例就可像函数一样被调用。常见模式：

• 在 __init__ 中保存装饰器参数和原始函数
• 在 __call__ 中编写执行逻辑，可自由使用实例属性（如 self.count += 1）
• 支持 __enter__/__exit__ 做资源管理，实现类似上下文的行为

装饰器链与执行顺序：从下往上套，从上往下跑

多个 @ 装饰器叠加时，书写顺序决定包装顺序：越靠近函数的装饰器越先执行（包装），但运行时越后执行（解包）。例如：

@log_time
@retry(max_retries=2)
def fetch_data(): ...

等价于 log_time(retry(max_retries=2)(fetch_data))。所以调用时：先进 log_time 的包装函数 → 再进 retry 的包装函数 → 最后执行 fetch_data。异常传播、返回值处理都要按这个嵌套层级考虑。