用装饰器统计类方法执行时间的技巧

本文深入剖析了在Python中为类方法（实例方法、类方法、静态方法）正确应用计时装饰器的关键陷阱与实战方案，直击“self/cls丢失导致TypeError”这一高频报错根源，强调wrapper函数必须显式声明并透传绑定参数（如def wrapper(self, *args, **kwargs)），否则不仅引发运行时异常，还会使functools.wraps失效、元信息丢失；同时澄清了带参装饰器、多线程/多进程下perf_counter()的适用边界，并给出可直接复用的安全代码模板——帮你避开隐秘坑点，写出健壮、精准、符合Python调用协议的类方法性能监控工具。

装饰器套在类方法上为什么直接报错 self 丢失？

因为普通函数装饰器默认接收 *args, **kwargs，但类方法第一个隐式参数是 self（或 cls），而未正确透传时，self 会被当成第一个位置参数吃掉，导致被装饰方法实际收到的 args 里多了一个本不该出现的 self，后续调用就崩了。

常见错误现象：TypeError: my_method() missing 1 required positional argument: 'self' 或参数错位、属性访问失败。

解决关键：装饰器内部的 wrapper 必须原样接收并转发 self（或 cls），不能只写 def wrapper(args, kwargs) 这种错误签名。

正确写法必须是：def wrapper(self, *args, **kwargs)（实例方法）或 def wrapper(cls, *args, **kwargs)（类方法）——否则一定出问题。

@timer 装饰类方法时，functools.wraps 会失效吗？

不会失效，但前提是装饰器本身写对了。很多开发者误以为加了 @wraps(func) 就万事大吉，结果发现 MyClass.my_method.__name__ 变成 wrapper 了——这说明 func 根本没传对，或者 wrapper 签名错误导致 @wraps 没生效。

验证方式：装饰后立刻检查 MyClass.my_method.__name__ 和 MyClass.my_method.__doc__ 是否还是原值。不是？那八成是 wrapper 没用 *args, **kwargs，或漏传了 self。

真正起作用的链条是：@wraps(func) → 依赖 func 是原始函数对象 → 所以 decorator 函数里必须正确接收并传递 func，且 wrapper 必须兼容方法调用协议。

带参数的计时装饰器怎么安全用于类方法？

带参数的装饰器（比如 @advanced_timer(unit='milliseconds')）嵌套更深，容易在第二层闭包里把 self 搞丢。核心原则不变：最内层 wrapper 的签名必须显式支持类方法上下文。

• 实例方法场景：最内层写成 def wrapper(self, *args, **kwargs)
• 静态方法场景：可按普通函数处理，用 def wrapper(*args, **kwargs)，但记得静态方法本身不传 self
• 类方法场景：写成 def wrapper(cls, *args, **kwargs)
• 想一劳永逸？统一用 def wrapper(*args, **kwargs)，然后靠 inspect.signature 判断首参数名，但小题大做，不推荐

示例（安全的带参版）：

def advanced_timer(unit='seconds'):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(self, *args, **kwargs):  # 显式支持实例方法
            start = time.perf_counter()
            result = func(self, *args, **kwargs)
            elapsed = time.perf_counter() - start
            if unit == 'milliseconds': elapsed *= 1000
            print(f"{func.__name__} took {elapsed:.4f} {unit}")
            return result
        return wrapper
    return decorator

多线程/多进程环境下，time.perf_counter() 还可靠吗？

可靠，但要注意作用域。在类方法里用 perf_counter() 没问题，它本身就是线程本地的，每个线程有独立计时器；跨进程时，各进程有自己的 perf_counter()，所以能分别统计子进程内方法耗时——但无法反映主进程调度开销。

容易踩的坑：

• 别在 multiprocessing.Pool 的 worker 函数里依赖主线程的计时器变量（比如闭包捕获的 start_time）
• 子进程里装饰的类方法，其耗时统计只含该进程内执行时间，不含 IPC、序列化、进程启动等 overhead
• 如果要测端到端延迟（比如 HTTP 请求 → 类方法处理 → 返回），得在更高层（如 API 入口）加装饰器，而不是只埋点在类方法里

简单说：计时本身没错，但你得清楚自己到底想测哪一段。

最常被忽略的一点：类方法装饰器一旦写错签名，错误可能延迟到运行时才暴露（比如某个分支路径没走 self），而不是定义时报错。上线前务必用带 self 和不带 self 的各类方法（实例/类/静态）都试一遍。

到这里，我们也就讲完了《用装饰器统计类方法执行时间的技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！