17370845950

Python装饰器本质是接收函数并返回新函数的“增强器”，通过包装动态添加行为；其执行逻辑为@decorator等价于func = decorator(func)，需确保装饰器及返回值均可调用。

Python装饰器的本质是函数的“增强器”——它不修改原函数代码，而是通过包装（wrap）方式动态添加新行为。理解这一点，就抓住了装饰器的核心：接收函数、返回函数、运行时介入。

装饰器的底层执行逻辑

装饰器实际是“函数调用 + 返回可调用对象”的组合。当写 @log_time 时，Python 会自动执行 func = log_time(func)。因此，装饰器本身必须是可调用对象（通常是函数），且返回值也必须是可调用对象（常为内部闭包函数）。

• 被装饰函数会被作为参数传入装饰器函数
• 装饰器内部通常定义一个嵌套函数（如 wrapper），完成前置/后置逻辑，并调用原函数
• 装饰器函数最终 return wrapper，而非 return wrapper()（后者会立即执行）
• 使用 functools.wraps(func) 可保留原函数的 __name__、__doc__ 等元信息，避免调试时混淆

带参数的装饰器怎么写

带参数的装饰器其实是“三层函数”结构：参数接收层 → 装饰器工厂层 → 包装执行层。例如 @retry(max_times=3) 并非直接作用于函数，而是先调用 retry(max_times=3) 得到真正的装饰器，再用它去装饰目标函数。

• 最外层函数接收装饰器参数（如 max_times），返回第二层函数
• 第二层函数接收被装饰函数，返回第三层 wrapper
• 第三层 wrapper 接收原函数的参数，控制逻辑并调用原函数
• 常见错误：漏掉某一层 return，导致返回 None，引发 TypeError: 'NoneType' object is not callable

实战中高频场景与写法

真实项目里，装饰器不是炫技工具，而是解决重复横切关注点的利器。下面几个案例覆盖大多数需求：

• 日志记录：在函数入口/出口打印时间、参数、返回值，适合调试和监控
• 权限校验：在视图函数或 API 处理前检查用户 token 或角色，不满足则直接返回错误
• 缓存管理：对纯计算函数（如斐波那契）做结果缓存，用 functools.lru_cache 是内置轻量方案；自定义可结合 Redis 控制过期与键生成逻辑
• 重试机制：对网络请求类函数自动重试，配合指数退避（exponential backoff）提升鲁棒性

容易踩坑的关键细节

装饰器看着简洁，但稍不注意就会引发隐蔽问题：

• 原函数参数不固定？用 *args, **kwargs 在 wrapper 中透传，别硬写参数名
• 装饰器加在类方法上？注意 self 或 cls 是第一个参数，wrapper 必须兼容
• 多个装饰器叠加（如 @auth @log @cache）？执行顺序是自下而上，即 @cache 最先被应用，@auth 最后生效
• 装饰器本身有副作用（如打开文件、启动线程）？确保在 wrapper 内部处理，而不是在装饰器定义时就执行