根本原因是装饰器未显式接收并转发self参数，导致绑定失败；正确做法是wrapper函数必须声明self参数，配合functools.wraps透传调用，而非用@staticmethod规避。
为什么@staticmethod和@classmethod不能直接替代实例方法装饰器
当你给实例方法加自定义装饰器后，调用时抛出 TypeError: my_method() missing 1 required positional argument: 'self'，根本原因不是装饰器写错了，而是装饰器没正确转发 self 参数。Python 实例方法在绑定调用时，会自动把实例对象作为第一个参数传入；而普通函数装饰器默认不保留这种绑定行为。
常见错误是直接在装饰器内部调用原函数却不传 self，或者用了 functools.wraps 却没处理好参数签名。
- 装饰器返回的包装函数必须接受
*args, **kwargs，且显式传递self（如果原方法是实例方法） -
functools.wraps(func)只复制元数据，不改变调用逻辑——它不帮你转发self - 别试图用
@staticmethod“绕过”问题：它会让方法彻底失去对实例的访问能力，不是修复，是阉割
如何写一个保持self绑定的通用装饰器
核心是让装饰器返回的函数仍能参与 Python 的方法绑定机制，即：当从实例上调用时，自动接收 self；从类上调用时，按需处理（比如抛错或转为静态行为）。
最稳妥的做法是用 functools.wraps + 显式参数透传，并确保包装函数签名与原函数一致：
立即学习“Python免费学习笔记（深入）”；
from functools import wraps
<p>def log_call(func):
@wraps(func)
def wrapper(self, *args, *<em>kwargs):
print(f"Calling {func.<strong>name</strong>} on {self}")
return func(self, </em>args, **kwargs)
return wrapper</p><p>class MyClass:
@log_call
def do_something(self, x):
return x * 2
- 必须把
self显式声明在wrapper参数列表里，不能只靠*args捕获 - 如果装饰器要支持实例方法、类方法、静态方法三态，得在
wrapper内部检查isinstance(self, type)或用inspect.signature动态解析，但会显著增加复杂度 - 避免用
lambda写装饰器：无法被wraps正确处理，且丢失函数名和文档
使用functools.partial或描述符协议的替代方案
如果你需要更灵活的绑定控制（比如装饰器本身带参数），单纯靠 wrapper(self, ...) 会不够用。这时得进入 Python 方法调用底层：方法是描述符，调用时触发 __get__。手动实现描述符能完全接管绑定逻辑。
简单场景下，functools.partial 可临时绑定部分参数，但它不解决 self 自动注入问题，仅适合已知 self 值的预绑定场景（如回调注册）。
- 描述符方案适合框架级工具，例如：
__get__(self, instance, owner)中判断instance是否为None来区分实例调用/类调用 - 不要为了“看起来高级”强行上描述符——90% 的业务场景，显式
self参数 +wraps就够了 - 第三方库如
decorator（pip install decorator）提供@decorator装饰器，可自动匹配原函数签名，减少手写wrapper(self, ...)的出错概率
调试时怎么快速定位self丢失的源头
别一上来就重写装饰器。先确认问题是否真的出在装饰器本身：
- 用
help(YourClass.your_method)看签名——如果显示your_method()（无self），说明wraps没生效或包装函数没声明self - 在装饰器内部加
print("args:", args, "kwargs:", kwargs)，观察实际传入参数数量和内容 - 临时删掉装饰器，用
MyClass().your_method()验证原方法是否正常；再加回装饰器，对比调用栈 - 注意装饰器顺序：如果叠加多个装饰器，
@A在外层、@B在内层，则B先执行，A的wrapper必须兼容B返回的函数签名
最常被忽略的是：装饰器工厂函数（带参数的装饰器）返回的才是真正的装饰器，而那个“真正装饰器”的 wrapper 才必须处理 self——很多人把参数逻辑和绑定逻辑混在同一层，导致第二层闭包漏掉 self。
