1. 一次代码评审引发的追问instance.method() 凭什么能调用先说一个我真实遇到过的场景。去年评审一个订单服务模块代码里有个OrderValidator类里面写了一个普通函数class OrderValidator: def validate(order): if order.amount 0: raise ValueError(订单金额必须大于0)这哥们写完后自己在本地测试用的是OrderValidator.validate(order)跑通了。但代码合并到主干后别的同事调用的时候写的是validator OrderValidator(); validator.validate(order)直接抛TypeError: validate() missing 1 required positional argument: self。评审会上争论了快半小时。有人说方法就是函数类里定义的函数就是方法有人说不对方法调用时会自动传 self还有人说静态方法要用 staticmethod 装饰。其实这些说法都对但都只说对了一半。真正的问题在于Python 里方法和方法调用根本不是一回事方法机制建立在函数之上但函数变成方法需要经过一个绑定binding的过程。你不把这一层看清楚遇到这种报错就只能靠试错解决运气好试对了运气不好就在群里喊玄学。这篇文章我想把方法绑定机制从头到尾拆一遍包括 bound method 到底是怎么产生的、类方法静态方法分别对应什么样的绑定规则以及我这些年做代码评审时最常被这些机制坑到的几个场景。如果你能把这套东西吃透以后看到TypeError: missing 1 required positional argument的时候第一反应不应该再是加个 self而是这个函数的绑定链路上哪里断了。2. bound method 的本质函数如何变成带记忆的方法对象2.1 先分清两个概念函数对象和方法对象在 Python 里你在类里写的 def 语句本质上是创建一个函数对象然后把它赋值给类的属性。注意这个动作它先是一个函数然后才是类的属性。举个例子class Demo: def greet(self): return fHello, {self.name}当你写Demo.greet的时候你拿到的是什么print(Demo.greet) # function Demo.greet at 0x...它是一个普通函数。没有绑定到任何实例上self也还没有具体值。但当你写demo Demo(); demo.greet的时候你拿到的就不再是函数了print(demo.greet) # bound method Demo.greet of __main__.Demo object at 0x...类型也变了from types import FunctionType, MethodType print(type(Demo.greet)) # class function print(type(demo.greet)) # class method这个bound method就是你听过的 bound method 术语的来源。它跟普通函数的区别是它把调用哪个函数和给 self 传什么值这两件事打包成了一个可调用对象。2.2 触发绑定的开关描述符协议get很多人不知道函数对象内部实现了__get__方法。这就是整个绑定机制的底层开关。当你访问demo.greet的时候Python 实际做了这么几件事在Demo类的属性表里找到greet这个属性值它是一个函数对象。因为函数对象实现了__get__Python 会调用greet.__get__(demo, Demo)。__get__返回一个新对象——绑定方法对象它把demo记录成了self的预定值。所以你可以这样手动复现绑定过程greet_bound Demo.greet.__get__(demo, Demo) print(greet_bound) # bound method Demo.greet of __main__.Demo object at 0x... print(greet_bound()) # Hello, 小明而如果你直接Demo.greet.__get__(None, Demo)拿到的是一个未绑定方法在 Python 3 里其实就是原函数unbound Demo.greet.__get__(None, Demo) unbound(demo) # 手动传 self等价于 demo.greet()这就是为什么Demo.greet(demo)和demo.greet()是等价的。前者是直接把函数对象当普通函数调用手动把实例作为第一个参数喂进去后者是通过__get__自动绑定实例你不需要管 self 怎么传。2.3 bound method 对象身上有什么你可以把绑定方法对象拆开看它有两个关键属性print(demo.greet.__self__) # 绑定到的实例对象 print(demo.greet.__func__) # 原始函数对象这两个属性加一起其实就解释了绑定方法的全部含义__func__是我要执行的代码__self__是代码执行时 self 指向谁。调用绑定方法的时候Python 执行的是__func__但会自动把__self__作为第一个参数插入。你可以完全不通过()调用来验证这一点func demo.greet.__func__ self_obj demo.greet.__self__ print(func(self_obj)) # 等价于 demo.greet()这个视角特别适合排查问题。当你碰到TypeError说参数数量对不上不要只看函数签名先看看__self__是谁。我有一次排查问题发现一个方法被当成装饰器返回了导致__self__被绑定到了函数对象上而不是实例上光看调用代码完全看不出来最后就是靠打印__self__才定位到问题。2.4 一个容易忽略的点绑定方法的身份问题绑定方法对象是在你访问属性的那一刻现算出来的。也就是说每次访问demo.greetPython 都会调用__get__重新生成一个新的方法对象print(demo.greet is demo.greet) # False这一点在代码评审时经常被忽视。有人会这样写class EventHandler: def __init__(self): self._handler self.handle # 保存绑定方法这种保存是没问题的因为self._handler在__init__里只算了一次持有一个稳定的绑定方法对象。但如果你在别的地方反复做self.handle is other.handle或把self.handle塞进 set、dict 做去重就要小心因为每次访问都是新对象基于同一次访问做身份比较才是安全的。还有一种更隐蔽的情况把绑定方法存到列表里做事件回调如果实例被销毁了绑定方法对象里还持有__self__的强引用会导致实例无法被垃圾回收。这块我后面在评审实战部分专门讲。3. 三种方法类型同源但不同命的三兄弟理解绑定机制之后再来对照着看三种方法类型就轻松多了——它们只是绑定的对象不同底层都是同一套__get__机制。3.1 实例方法绑定到实例实例方法就是我们上面一直在分析的默认形态。你写的绝大多数 def 方法只要不是被classmethod或staticmethod装饰都是实例方法。它的特征是第一个参数约定俗成叫self代表实例本身。通过实例访问时自动绑定到该实例调用时不需要也不能传 self。通过类访问时拿到的是原始函数想调用必须手动传入实例。表格看会更直观访问方式拿到的类型调用方式instance.methodbound methodinstance.method()自动传 selfClass.methodfunctionClass.method(instance)手动传 selfClass.method(instance)等价于instance.method()两者结果完全一样这里有一个新手最容易晕的问题既然Class.method(instance)和instance.method()等价那是不是说在类内部调用自己类的方法时也应该像普通函数那样调用不是。类内部调用实例方法还是要通过实例class OrderService: def validate(self, order): return order.amount 0 def process(self, order): # 正确通过 self 访问自动绑定 if not self.validate(order): raise ValueError(invalid)如果你在process里写OrderService.validate(order)又会触发 missing self。这种 bug 在重构的时候特别容易引入因为一开始你可能是在类外面调用后来把逻辑挪进类里面忘了改调用方式。3.2 类方法绑定到类classmethod装饰的方法绑定目标从实例变成了类。第一个参数约定俗成叫cls。class Config: env prod classmethod def show_env(cls): return f当前环境: {cls.env} def print_env(self): return Config.show_env() # 类和实例都能调用这里有两个细节值得注意。第一cls不一定是Config本身。如果子类继承了show_env通过子类调用时cls会被绑定到子类上class DevConfig(Config): env dev print(DevConfig.show_env()) # 当前环境: dev这个特性很有用我见过很多库就是靠cls来获取具体子类的配置从而实现模板方法模式。第二通过实例访问类方法时Python 会自动把实例对应的类作为绑定目标cfg Config() cfg.show_env() # 等价于 Config.show_env()也就是说instance.class_method()拿到的绑定对象__self__是类而不是实例。这个行为跟实例方法有本质区别也是我在评审时判断作者到底懂不懂三种方法类型的试金石。3.3 静态方法不绑定任何东西staticmethod装饰的方法在访问时不会触发自动绑定。它的本质就是一个恰好放在类命名空间里的普通函数。class MathUtils: staticmethod def add(a, b): return a b # 类的调用和实例的调用结果都是拿到原始函数 print(MathUtils.add) # function MathUtils.add at 0x... print(MathUtils().add) # function MathUtils.add at 0x...正因为没有绑定静态方法通过类和通过实例访问拿到的都是同一个函数对象print(MathUtils.add is MathUtils().add) # True这一点跟实例方法又不一样——实例方法因为每次访问都要绑定所以instance.method is instance.method是 False。理解这个区别后面看内存泄漏问题就很快。静态方法适合放什么工具函数、纯函数、不依赖类状态和实例状态的操作。比如类型转换、数值计算、字符串清洗。它跟模块级函数的区别仅仅是它写在类里面语义上跟这个类强相关调用时能通过类名.方法名找到方便按业务模块组织代码。3.4 一张表说清三兄弟方法类型装饰器绑定目标第一个参数通过类访问返回通过实例访问返回实例方法无实例selffunction不绑定bound method类方法classmethod类clsbound methodbound method绑定到类静态方法staticmethod无无特殊要求functionfunction我一直认为能把这三种类型背后绑定到谁说清楚才算真正掌握 Python 的方法体系。很多人背了语法规则但不会用就是因为只记住了要加 classmethod/staticmethod没有理解这层装饰器实际上是在改写__get__的行为。4. 代码评审中遇到的高频方法绑定事故与排查链路4.1 事故一把类方法当实例方法调用或者反过来这是出现频率最高的一类问题。我摘一个简化过的评审案例class CsvExporter: HEADERS [名称, 价格] classmethod def get_headers(cls): return cls.HEADERS def export(self, path): with open(path, w) as f: # 问题这里直接用了类名调用类方法虽然能跑但写死了类 f.write(,.join(CsvExporter.get_headers()))严格说这段代码能跑不是一个 bug但它是一个绑定设计上的坏味道。正确做法是写成self.get_headers()或type(self).get_headers()。为什么要这样因为类方法绑定的意义就在于它允许子类通过继承覆盖这个类方法的行为。你在内部写死CsvExporter一旦子类SpecialCsvExporter继承了export并想改写HEADERS这个方法拿到的仍然是父类的HEADERS行为就错了。评审中我一般会给出两个修复建议如果类方法是想让子类按多态方式覆盖调用处应写self.get_headers()因为实例也能调用类方法并且绑定到实际类型。如果这个类方法真的只属于当前类不需要被子类改写那就要考虑它是不是该写成静态方法或者干脆判断是不是用错了设计模式。这个案例提醒我们方法调用时写的那个前缀类名还是实例名不只是语法问题它决定了绑定到谁绑定到谁就决定了能不能利用多态。4.2 事故二在装饰器或回调中丢失绑定这个坑比较深。看一段我改造过的真实代码class MetricsCollector: def __init__(self): self._count 0 def increment(self): self._count 1 def schedule_batch(callback, times): for _ in range(times): callback() collector MetricsCollector() schedule_batch(collector.increment, 3)这段代码没问题因为collector.increment是绑定方法传进schedule_batch之后每次调用都还能带上collector。但如果你图省事把函数对象直接传进去schedule_batch(collector.increment, 3) # 正确 schedule_batch(MetricsCollector.increment, 3) # 错误TypeError: missing 1 required positional argument: self这个错误大家容易理解。但还有一种更隐蔽的发生在装饰器里。假设有人为了做性能分析写了这么个装饰器def log_call(func): def wrapper(*args, **kwargs): print(f调用 {func.__name__}) return func(*args, **kwargs) return wrapper当它装饰一个实例方法时class Service: log_call def run(self): return running这里装饰发生在类定义阶段log_call接收到的func是普通函数。wrapper在运行期被调用时如果是从实例访问的instance.run会绑定到wrapper然后wrapper(*args, **kwargs)再把包含self在内的参数原封不动转给func所以没问题。真正出问题的是有些人自作聪明在装饰器内部提前做方法查找或者缓存def cache_method(instance, method_name): # 基于实例缓存绑定方法看起来没问题 method getattr(instance, method_name) return method这能跑但如果类上这个方法是重写自基类的你就要小心缓存的是哪个类上的方法。这里衍生出了一个更隐蔽的坑super()返回值上做方法访问时的绑定对象。4.3 事故三super() 与绑定的相爱相杀super()返回的是一个代理对象它有一个特点当你从super(type, obj)上访问方法时Python 会做一个跳过当前类型从基类开始找的效果但绑定对象仍然是原始实例obj。举个例子class Base: def hello(self): return Base class Child(Base): def hello(self): base_hello super().hello # 这是个绑定方法self 指向 Child 实例 return fChild - {base_hello()}很多人看到super().hello返回的是绑定方法就会想既然它已经绑定到Child实例上那我能不能把它保存下来以后绕过多态调用实际上super().hello跟self.hello在这次调用上是不同的——self.hello()会再次从Child类开始查找可能又回到Child.hello造成递归而super().hello()直接从Base开始查找只执行基类版本。如果你把base_hello存下来持续调用它的__self__一直是那个Child实例但方法查找是被固定的基类版本。这个机制本身设计得很好但我在评审中见过这样的代码def call_later(self): callback self.hello # 想在多态场景下也能调 ...当self是子类实例时self.hello绑定的是子类的hello。这是符合预期的。但如果你在基类的__init__里写了callback self.method然后这个绑定方法在子类__init__继续执行之前就被调用了就会发生一个经典陷阱子类的属性尚未初始化绑定方法里已经用到了一个不存在的状态。排查这种问题的关键链路是这样的发现异常发生在某个回调里但异常信息里没有调用栈来源。在绑定方法被创建的地方打印method.__self__的类型和属性。对比创建时机和实际调用时机确认是否是绑定对象早于实例初始化完成。4.4 事故四绑定方法被强引用导致的内存泄漏这是我在一个后台任务系统里踩到过的坑只出现过一次但排查过程非常典型。系统里有一个事件分发器把大量处理器方法注册到一个全局列表class EventHub: def __init__(self): self._handlers [] def register(self, handler): self._handlers.append(handler) hub EventHub() class Worker: def on_event(self, event): print(event) worker Worker() hub.register(worker.on_event) # 把绑定方法注册进去问题在于worker.on_event是一个绑定方法它内部的__self__强引用着worker实例。只要_handlers列表还活着worker就永远无法被垃圾回收。哪怕业务上你早就把worker变量删掉了它还是会被这个列表拖住。我们当时是在内存监控里发现内存只增不减dump 堆之后发现大量 Worker 实例存活顺着引用链找发现全部挂在_handlers列表的绑定方法对象上。解决方案有两种第一种是改 API注册时改为弱引用import weakref hub.register(weakref.ref(worker)) # 注册时保存弱引用回调时再取第二种是让注册接口只接收(instance, method_name)这样的信息回调时再动态getattr(instance, method_name)。这样容器里只保存实例名不保存绑定方法实例可以正常回收。这个案例的教训是绑定方法对象是一个实例 函数的捆绑包它天然会持有实例。在事件系统、信号系统、订阅系统里如果生命周期管理不当每个注册都会变成一条泄漏的引用链。评审时我特别留意self.xxx作为回调传进某个长期存活的容器这种情况。4.5 事故五inspect.signature 看到的方法签名陷阱还有一个评审中常见的认知偏差跟绑定机制直接相关import inspect class Service: def process(self, payload): pass print(inspect.signature(Service.process)) # (self, payload) print(inspect.signature(Service().process)) # (payload)同一个方法通过类访问时签名里带self通过实例访问时签名里没有self。你如果把这两种签名混淆做参数校验、接口文档自动生成、依赖注入时就会出错。我在评审依赖注入框架相关代码时发现有人手写了一个参数注入器取参数名列表时用的是param_names list(inspect.signature(cls.method).parameters)如果cls.method是通过类访问的实例方法param_names里就会混入self。注入器把self当成一个需要注入的参数导致调用时参数错位。正确的做法是你想要的是方法签名中剔除 self/cls 后的业务参数就应该从绑定方法上取签名或者显式过滤掉第一个参数。这两种方式在语义上是有细微差别的我推荐后者因为从绑定方法上取签名虽然会过滤掉 self但如果那个方法恰好是个类方法你会发现cls也被吃掉了一个逻辑不够清晰。像这种同一个逻辑函数因为绑定状态不同暴露出来的签名不同是 Python 方法机制特有的、也是最容易在生产环境引发隐性 bug 的点。很多自动化工具测试 mock、序列化、RPC 路由都会踩这个坑。4.6 事故六误以为静态方法不能访问类变量这个问题的起因是语法上的混淆。有同事在评审时说静态方法既然不绑定那它就没法访问类变量所以静态方法没用。这个说法是错的。静态方法本身不接收cls不代表它不能通过类名访问类变量class Machine: model T1000 staticmethod def describe(): return f型号: {Machine.model} print(Machine.describe()) # 型号: T1000但它确实不能像类方法那样感知子类覆盖class BetterMachine(Machine): model T2000 print(BetterMachine.describe()) # 还是 型号: T1000这恰恰是静态方法和类方法在设计意图上最本质的区别静态方法强调与类相关但依赖具体类名类方法强调与类相关且跟随实际类型。如果你需要多态感知类方法是正确的选择如果你要的是一个铁板一块的逻辑静态方法反而更安全因为它不会因为子类覆盖而改变行为。5. 从评审到设计方法绑定视角下的 API 思路5.1 用绑定机制倒推该选哪种方法我在评审时常给团队一个简单判断流程方法里用到了self或实例状态 → 实例方法。方法里完全不用实例状态但需要访问类状态且希望子类覆盖类状态时能跟着变 → 类方法。方法既不用实例状态也不依赖类状态纯粹是工具逻辑 → 静态方法。方法需要返回一个类的实例工厂函数 → 类方法最合适。第四点值得展开。工厂方法天然适合用类方法因为cls会绑定到实际调用的类上子类调用时可以返回子类实例。比如日期解析库class DateParser: format %Y-%m-%d classmethod def parse(cls, text): return cls(datetime.strptime(text, cls.format)) class SlashDateParser(DateParser): format %Y/%m/%dSlashDateParser.parse(2024/01/01)会把cls绑定到SlashDateParser。这个设计如果换成静态方法就只能在静态方法里写死某个类或者手动DateParser判断没法这么优雅。5.2 我的一条评审清单我现在每次做方法相关的代码评审心里会过这么几条这个方法是被谁调用的实例调用还是类调用有没有可能把绑定对象存起来导致实例泄漏类方法的cls有没有被正确利用有没有写死父类名导致子类多态失效静态方法的选择是不是真的合理它需不需要感知子类覆盖super().xxx的使用有没有固定查找链路的副作用有没有把类方法签名的cls或者实例方法签名的self当成业务参数处理自动化工具尤其要查这一条。这五条看起来简单但每一条背后都有真实事故支撑。我在正文里提到的六个事故类型基本覆盖了我这几年一半以上的方法相关 Reviewer 注释。5.3 给收方法作参数的框架设计者提个醒最后再说一个设计层面的经验。写框架、写装饰器、写回调系统的人要特别注意使用者传入的是函数还是绑定方法。最稳妥的做法是在接纳外部回调时不要假设它是普通函数也不要假设它是绑定方法。统一用inspect.ismethod(func)判断绑定方法用inspect.isroutine(func)判断一般可调用对象。需要拿实例时用getattr(func, __self__, None)是可以的但要意识到__self__不一定存在。我之前写的调度器就是这样设计的对外接口只接受可调用对象然后内部统一把它们转成一个统一的CallableWrapper这个 wrapper 负责解析签名、处理参数注入、管理生命周期。这样可以避免把底层绑定差异暴露给业务方。不过也要提醒一句过度封装有时候会掩盖问题。如果调用方传入一个类方法你的统一接口解析出来的第一个参数是cls还是业务参数取决于你从哪个入口拿签名。我建议在 wrapper 里显式记录方法属性和绑定状态不要事后猜。写在最后的实操体会方法绑定这个机制乍看是 Python 基础语法但它的影响面远比想象中大。我自己排查内存泄漏、设计回调框架、做依赖注入参数解析时都反复回到__get__和 bound method 这两个原点。你在实际项目中不一定每天都会遇到这些边界情况但只要遇到一次没有底层认识就很难走出来。如果让我给一个最实际的建议那就是当你对一个方法调用方式不确定时在 REPL 里跑一下type(obj.method)和obj.method.__self__比翻文档管用得多。看懂了这两个值方法绑定对你来说就不再是黑盒了。