装饰器性能开销取决于内部逻辑：简单操作几乎无感，而同步 I /O、未缓存计算等会显著拖慢执行；需避免耗时操作、重复包装及高频状态更新，并用 timeit/cProfile/ 压测评估；轻量写法应“快进快出”，复杂场景宜换 AOP 或 contextvars。
Python 装饰器本身引入的性能开销极小，但具体影响取决于装饰器内部逻辑——简单日志或计时几乎无感，而同步 I /O、深度递归或未缓存的计算型装饰器可能显著拖慢被修饰函数。
装饰器何时会明显拖慢执行速度
以下情况需特别注意性能损耗：
- 在装饰器中执行耗时操作：比如每次调用都读取文件、查询数据库、解析大 JSON、生成 UUID 或调用 time.sleep()；这类操作应移出装饰器主体，或改用惰性求值 / 缓存机制。
- 未避免重复包装 ：对已装饰函数再次应用相同装饰器（尤其带参数的类装饰器），可能意外叠加多层代理，增加调用 栈深度和对象创建开销。
- 在高频循环内使用带状态的装饰器：例如用装饰器维护计数器并频繁更新共享字典，会引发隐式锁竞争或哈希冲突，尤其在多线程下更明显。
如何安全评估装饰器的实际开销
别依赖直觉，用数据说话：
- 用 timeit 对比原始函数与装饰后函数的单次调用耗时（注意排除首次导入 / 编译影响）；
- 对关键路径函数做 cProfile 分析，确认装饰器相关帧是否出现在 热点 中；
- 在真实业务上下文中压测，观察 QPS、P99 延迟变化——有时微秒级增幅在万级 TPS 下会放大为可观的系统延迟。
轻量装饰器的推荐写法（兼顾可读与性能）
遵循“快进快出”原则：
立即学习“Python 免费学习笔记（深入）”；
- 避免在 __call__ 或闭包内做任何非必要计算，把重逻辑下沉到被修饰函数内部或独立服务中；
- 使用 functools.wraps 仅用于保留元信息，它本身开销可忽略，但缺失会导致调试困难、类型检查失效；
- 若需条件生效（如仅 DEBUG 模式记录日志），在装饰器工厂中提前判断，而非每次调用都 if 判断。
不适合用装饰器的场景（该换方案了）
当出现以下信号，说明装饰器已超出合理使用边界：
- 你开始给装饰器加配置开关、动态启用 / 禁用、运行时热插拔——这其实是 AOP 框架或中间件职责；
- 多个装饰器嵌套导致调用栈过深（> 5 层），traceback 难以阅读，且 sys.setrecursionlimit 被反复触碰；
- 需要跨函数共享复杂上下文（如请求 ID 透传、事务状态），应优先考虑 contextvars 或显式参数传递，而非靠装饰器隐式注入。
