做 Python 时间长了会发现语言里很多“魔法方法”并不是拿来炫技的而是专门解决真实场景下的调用问题。__call__这个词不少人只停留在“能让对象像函数一样被调用”的认知层面可一旦要写插件系统、回调分发、策略配置它和参数解包、关键字参数组合起来的威力会比想象中大得多。把这串标题拆开无非三件事把一个类实例变成可调用对象调用时能用*和**把序列、字典展开传进去对象内部再通过*args、**kwargs收住参数并做二次分发。这三件事串起来就是一套非常顺滑的参数传递机制。这篇文章我会从原理、实操、踩坑三个层面展开争取让新手能直接抄也让有经验的读者能查漏补缺。1. 从函数的“皮”看可调用对象__call__做了什么1.1 实例并不是函数但可以表现得像函数在 Python 里一个东西能不能被调用并不取决于它是不是Function类型而是看它的类型里有没有__call__方法。这个很好验证class Greeter: def __init__(self, prefixHello): self.prefix prefix def __call__(self, name): return f{self.prefix}, {name} g Greeter(Hi) print(g(Alice)) print(callable(g))我第一次看到这种写法时会忍不住想这不就是把方法名从greet换成了__call__吗好像只是语法糖。但真正理解之后会发现Python 的调用协议在底层是非常统一的g(Alice)这个表达式解释器实际执行的是type(g).__call__(g, Alice)。也就是说所有能被调用的东西最终都走到了“类型里那个__call__方法”上。这解释了为什么函数、类、实例可以放在同一个回调列表里而不报错。只要callable()返回True外部调用者根本不用关心它到底是个函数还是个带状态的类实例。这种“统一调用入口”的设计是后面所有参数传递技巧的地基。1.2 可调用对象比普通函数多出来的“记忆”能力普通函数其实也可以挂属性比如fn.counter 0但一个类实现__call__之后状态管理会自然很多初始化时配置参数调用时只关心本次输入调用后还能把过程数据放在对象上。举个我常用的计时器例子import time class Timer: def __init__(self, labeltimer): self.label label self.cost 0.0 self.calls 0 def __call__(self, fn, *args, **kwargs): start time.perf_counter() result fn(*args, **kwargs) self.cost time.perf_counter() - start self.calls 1 return result timer Timer(heavy) result timer(calculate_sum, [1, 2, 3]) print(timer.cost, timer.calls)这里的关键点是__call__内部不仅收住了fn和后续参数还能通过对象属性保留统计信息。如果换成闭包也不是不行但状态多了之后闭包作用域里那堆nonlocal变量会让人头大。可调用对象则相当于把闭包里的“环境变量”升级成了“实例属性”读写更清晰也更容易在测试中单独断言。2. 参数解包与关键字参数如何在__call__内外流动2.1 调用侧的星号把容器摊开成实参参数解包听上去很高级本质上就是把一个容器按规则“摊开”后再扔给函数。Python 里调用时使用*可以把可迭代对象展开成位置参数**可以把字典展开成关键字参数def point(x, y, z): return (x, y, z) axis (1, 2) extra {z: 3} print(point(*axis, **extra))注意顺序位置参数必须在关键字参数之前所以point(*axis, **extra)没问题但你要是写point(**extra, *axis)直接语法错误。这里还有一个经常被忽略的点**extra展开后字典的键必须和函数形参名精确匹配否则会报unexpected keyword argument。也就是说解包不是“往里塞一堆东西”这么粗糙它同样遵循 Python 的参数绑定规则。这个机制对__call__完全适用。因为一个实例被调用时本质上就是在调用type(instance).__call__(instance, ...)所以外部传参时照样可以class Box: def __call__(self, *args, **kwargs): return args, kwargs box Box() items [1, {mode: fast}] print(box(*items, debugTrue))在可调用对象上做参数解包最大的好处是上游逻辑完全可以先拼好一组参数再以极松耦合的方式传递给下游下游不管你是函数还是类实例只要能调用就行。2.2 定义侧的星号__call__里的参数收拢与调用侧的“展开”对应定义侧可以用*args和**kwargs把任意参数“收拢”。比如一个最简单的转发器class Proxy: def __call__(self, *args, **kwargs): print(positional:, args) print(keyword:, kwargs)这里args是一个元组kwargs是一个字典。如果你写过一点框架代码应该对这种“透传”模式很熟悉我不关心具体有哪些参数但我要保证把它们一个不少地交给下一层。下面这个事件分发器的雏形就是典型的透传class Hook: def __init__(self): self.funcs [] def add(self, func): self.funcs.append(func) def __call__(self, *args, **kwargs): return [func(*args, **kwargs) for func in self.funcs]Hook()(*(1, 2), **{x: 3})这种调用展开发生在外部收拢发生在__call__再次展开发生在内部func(*args, **kwargs)。一条链路上同样的星号用了三次这就是标题里“参数解包与关键字参数在可调用对象中的传递”最直白的体现。2.3 位置、默认值、仅关键字参数的正确排队很多人写__call__时只图省事一律*args, **kwargs。真正规范的写法要按优先级排参数顺序位置参数、默认参数、*args、仅关键字参数、**kwargs。比如class Trainer: def __init__(self, base_lr): self.base_lr base_lr def __call__(self, epoch, *, verboseFalse, **extras): ...这里epoch是必选位置参数verbose是仅关键字参数extras用来接收框架可能传进来的扩展参数。如果你希望某个位置参数在调用方解包时可以放心传递同时又不希望它被同名关键字参数覆盖可以用/把它标记为纯位置参数class Parser: def __call__(self, text, /, *, strictFalse): ...这样Parser()(content, strictTrue)没问题但Parser()(textcontent)会报错。这个细节在写公开接口时特别有用它能明确告诉调用方这个参数必须通过位置传入省掉不少误用风险。3. 实操案例一个统一参数转发的事件分发可调用对象3.1 需求与设计目标我把工作里比较典型的一个场景简化一下系统中会被触发很多事件每个事件希望支持多个监听函数监听函数能接收不同的位置参数和关键字参数触发方可能预先拿到了一个参数元组和一个参数字典需要在调用事件中心时直接展开传递。这个场景如果不用可调用对象通常会写hub.emit(start, *data, **options)这也没问题。但一旦事件中心本身要被当作回调传给更上层的框架那么“事件中心实例可以直接被调用”就有优势了上层框架只认可调用对象不认你自定义的emit方法名。3.2 核心代码与解包调用方式下面这个EventHub实现了订阅、退订和统一触发class EventHub: def __init__(self): self.handlers [] def subscribe(self, handler): self.handlers.append(handler) def unsubscribe(self, handler): self.handlers.remove(handler) def __call__(self, *args, **kwargs): if not self.handlers: return [] results [] for handler in self.handlers: results.append(handler(*args, **kwargs)) return results使用时的完整链路def on_start(phase, *, verboseFalse): return fstart {phase}, verbose{verbose} def on_end(*args, **kwargs): return end: ,.join(str(a) for a in args) hub EventHub() hub.subscribe(on_start) hub.subscribe(on_end) data (build,) options {verbose: True} result hub(*data, **options) print(result)注意on_start的phase会被data展开后填充verbose会被options展开后填充。on_end因为签名很宽松会把所有位置参数和关键字参数都接住。这里最容易被忽略的是异常处理如果一个 handler 抛了异常整个调用链会中断。真实项目中我通常会 catch 一下把异常对象放进结果里或者触发差级重试。3.3 用 inspect.signature 校验并补全可读性直接用*args, **kwargs确实灵活但也会带来一个副作用调用方无法从inspect.signature上看出这个对象到底支持什么参数。要解决有几个办法。第一在设计时尽可能用显式形参。比如你的可调用对象其实只关心event和payload那就写成class Dispatcher: def __call__(self, event, payloadNone, **extra): ...这样 IDE 提示和代码阅读都会直观很多。第二如果必须保持*args, **kwargs可以在调用内部做“白名单校验”把不认识的参数直接报错而不是静默吞掉class StrictHub: def __call__(self, *args, **kwargs): allowed {event, payload} unknown set(kwargs) - allowed if unknown: raise TypeError(funexpected keywords: {unknown})第三甚至可以直接给实例绑定一个__signature__让inspect.signature返回一个假想的签名。这个操作适合写对外 SDK 时用枚举参数名和默认值提升调用方体验from inspect import Signature, Parameter class Demo: def __call__(self, *args, **kwargs): return args, kwargs Demo.__call__.__signature__ Signature([ Parameter(x, Parameter.POSITIONAL_OR_KEYWORD), Parameter(y, Parameter.POSITIONAL_OR_KEYWORD, default1), ])虽然这是少数高级用法但遇到“接口需要灵活、文档又不能丢”的场景时非常管用。4. 这些坑我基本都踩过关键字参数传递的排查清单4.1 “got multiple values for argument” 是怎么冒出来的这是把位置参数和关键字参数混在一起时最经典的报错。看这段代码class Demo: def __call__(self, value, **kwargs): return kwargs.get(scale, 1) * value demo Demo() demo(3, value4)报错内容会提示__call__() got multiple values for argument value。原因很简单3已经通过位置传给了value后面value4又想用关键字再传一次。Python 不允许同一个形参被重复赋值。解决方式有两种一是把value改成纯位置参数这样demo(3, value4)还是会报错不过是另一种更明确的错误二是设计时就约定好不要把一个参数既当位置参数又当关键字参数使用。很多函数式接口会干脆用/强制分流就是这个道理。4.2 共享可变默认值每次调用都在累积旧数据Python 的默认参数值只会在定义时计算一次。如果你在__init__或__call__里写了history[]那么所有实例或所有调用都会共享同一个列表。class BadLogger: def __init__(self, records[]): self.records records a BadLogger() b BadLogger() a.records.append(x) print(b.records)b.records会打印出[x]因为两个对象用的是同一个列表对象。这跟可调用对象结合起来特别有迷惑性你可能创建了多个 logger以为它们各记各的结果数据串了。处理办法是统一用None作为哨兵值class GoodLogger: def __init__(self, recordsNone): self.records [] if records is None else records有状态的可调用对象尤其要把这个习惯刻进肌肉记忆否则“上次调用的参数残留”会成为非常难排查的线上问题。4.3 宽松**kwargs掩盖拼写错误如果__call__里写的是options kwargs.get(treshhold, 10)恭喜你这个treshhold拼错了但代码不会报错因为get找不到键时返回默认值。结果就是你的逻辑一直用默认阈值运行外部传进来的真阈值完全没生效。这种问题比直接报错更讨厌因为它不给你任何提示。我的排查经验是凡是用**kwargs收参数尽量不要用get无限度地兜底。要么在处理之前做一次键集合校验要么从kwargs中pop出已知键后检查是否还有残留。加了两行校验之后很多“看似玄学”的问题能少一大半。4.4 可调用对象与函数身份的边界callable(obj)返回True不代表obj(...)一定成功__call__内部也可能抛异常这一点大家都知道。容易被忽略的是另外两个边界第一可调用对象不是函数isinstance(obj, types.FunctionType)是False某些框架会对“函数”做特殊处理你传一个可调用实例进去它可能跳过或者报不支持第二在序列化场景里函数不能序列化带状态的可调用对象同样不能除非你自己实现序列化逻辑。所以别把可调用对象当成万能替代品该传函数时传函数该传对象时传对象。5. 我平时更推荐的使用姿势5.1 适合上可调用对象的四类场景不是所有地方都需要把实例变函数根据我的使用心得有四类场景收益最大。一是策略模式把不同策略做成不同可调用对象上层只调strategy(data)不用管内部实现二是回调分发事件中心持有多个可调用对象调用入口统一成obj(*args, **kwargs)三是装饰器工厂用一个类实例记录调用次数、耗时、出参入参然后直接把实例当装饰器用四是参数化接口封装把基础配置放进__init__把每次变化的参数放进__call__避免每次调用都传一长串配置。这四类场景有一个共同点状态和配置在初始化时准备好行为在执行时暴露。如果不符合这个特征那用普通函数更直接。5.2 和闭包、partial 竞争时怎么选闭包也能做状态保持functools.partial也能预填参数那什么时候非用可调用对象不可我一般这样判断状态只有一个两个闭包就行状态一堆还要被继承、被测试、被独立复用的选可调用对象单纯想固定前几个参数functools.partial就够没必要专门包一个类。from functools import partial def log(level, message): return f[{level}] {message} info partial(log, INFO) print(info(start))你看这种场景用partial干净利落。可调用对象更适合的状态版本可以是class LoggerWithLevel: def __init__(self, level): self.level level def __call__(self, message, **kwargs): suffix kwargs.get(tag, ) return f[{self.level}] {suffix} {message}简单对比一下方案状态管理复用性适合场景普通函数依赖全局变量或外部容器一般无状态逻辑闭包捕获外层变量中等轻量级计数器、前缀处理functools.partial绑定参数值中等入参固定、逻辑不变可调用对象类属性完整管理高状态复杂、需要单元测试和继承扩展5.3 一个小技巧让签名不再“面目模糊”使用*args, **kwargs的可调用对象有个通病IDE 提示看不到参数代码阅读者只能去翻实现细节。我常用的补救手段是写好类文档字符串并且在__call__的第一行注释里说明参数结构。更高阶一点直接覆盖__signature__或在文档里附一个调用示例。如果你用的是显式参数那就没必要折腾了。我自己更推荐“显式参数为主**kwargs做扩展兜底”因为这种设计在可读性和灵活性之间最平衡。记住一个原则可调用对象是一种封装技巧不是炫技。如果一个类的全部价值只是实现一次__call__又没有任何状态那它就是个函数别硬包一层类。最后说一点个人体会在我实际维护的项目里可调用对象搭配参数解包用得最顺的场景是底层框架完全不知道上层业务长什么样的情况下把参数原样透传给插件。如果你也遇到类似设计建议从最小的显式签名开始写等确实需要透传时再加*args, **kwargs。这样踩坑最少后续也最好维护。