为何Python类方法作为装饰器时首个参数会变化？

为什么会出现这种矛盾的行为？ #

你观察到的现象本质上是Python的方法绑定机制和装饰器执行时机共同作用的结果：

• 当直接调用c.decorator()时，decorator作为实例方法被调用，Python会自动把实例c绑定到方法的第一个参数self上，这符合我们对实例方法的预期。
• 但当用@decorator装饰函数decorated时，装饰器的执行是在模块加载阶段——此时类C还没有被实例化，decorator只是类的一个未绑定方法（本质上就是普通函数）。当装饰器语法生效时，Python会直接调用这个未绑定的函数，并把被装饰的decorated函数作为第一个参数传入，这就导致self变量此时指向的是被装饰的函数，而不是类实例。

这种编码模式是否被广泛使用？ #

答案是几乎不会。这种写法严重违背了Python开发者的直觉：类里的非静态/类方法，默认应该和实例绑定，而用作装饰器时却完全脱离了实例上下文，很容易让阅读和维护代码的人产生困惑。在实际开发中，大家更倾向于用更清晰的方式实现装饰器需求：

• 如果装饰器不需要依赖类/实例状态，直接把它定义在类外面作为普通函数。
• 如果需要依赖类状态，用@classmethod修饰装饰器。
• 如果需要依赖实例状态，通常会改用类装饰器，或者在实例创建后动态绑定装饰逻辑（这种场景也比较少见）。

使用时的潜在陷阱 #

这种模式的坑点非常多，主要包括：

• 参数语义混淆：同一个函数，作为实例方法调用时self是类实例，作为装饰器时self是被装饰函数，这种语义的切换会让代码逻辑变得极其混乱，排查bug难度陡增。
• 无法访问实例状态：当作为装饰器使用时，decorator没有绑定到任何实例，内部的self其实是被装饰函数，完全无法访问类实例的属性或其他方法——这等于完全浪费了把它放在类里的意义。
• 模块加载阶段的风险：装饰器在模块导入时就会执行，此时类可能还没有完成初始化，甚至没有任何实例存在。如果decorator里有依赖实例状态的逻辑，会直接抛出错误。
• 装饰后的方法逻辑混乱：被装饰的decorated方法，调用时的self是类实例，但它的装饰过程却和实例无关，整个调用链条的逻辑非常绕，很容易出现预期之外的行为。

总结 #

除非有非常特殊的场景需求（但我几乎想不到合理的场景），否则强烈建议避免这种写法。Python提供了多种更清晰的装饰器实现方式，完全可以替代这种容易造成混淆的模式。

内容的提问来源于stack exchange，提问作者Kazuya Hatta