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