Python装饰器本质是接收函数并返回新函数的“增强器”，通过包装动态添加行为；其执行逻辑为@decorator等价于func = decorator(func)，需确保装饰器及返回值均可调用。
Python装饰器的本质是函数的“增强器”——它不修改原函数代码，而是通过包装（wrap）方式动态添加新行为。理解这一点，就抓住了装饰器的核心：接收函数、返回函数、运行时介入。
装饰器的底层执行逻辑
装饰器实际是“函数调用 + 返回可调用对象”的组合。当写 @log_time 时，Python 会自动执行 func = log_time(func)。因此，装饰器本身必须是可调用对象（通常是函数），且返回值也必须是可调用对象（常为内部闭包函数）。
- 被装饰函数会被作为参数传入装饰器函数
- 装饰器内部通常定义一个嵌套函数（如
wrapper），完成前置/后置逻辑，并调用原函数 - 装饰器函数最终 return wrapper，而非 return wrapper()（后者会立即执行）
- 使用
functool可保留原函数的
s.wraps(func)__name__、__doc__等元信息，避免调试时混淆
s.wraps(func)带参数的装饰器怎么写
带参数的装饰器其实是“三层函数”结构：参数接收层 → 装饰器工厂层 → 包装执行层。例如 @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内部处理，而不是在装饰器定义时就执行
