从“类型体操”到工程设计用 Python 解释协变、逆变与不变在 Python 里很多人第一次听到“协变、逆变、不变”时都会本能地皱眉这是不是又是一套只存在于类型系统里的抽象概念平时写业务代码、做 Web 后端、数据处理、自动化脚本真的需要懂这些吗我的答案是如果你只是写几十行脚本可以暂时不懂但如果你在设计事件处理器、回调函数、SDK、框架接口、插件系统、只读集合接口那么你迟早会碰到它。协变、逆变、不变本质上不是“类型体操”而是在回答一个非常朴素的工程问题当Dog是Animal的子类时Container[Dog]能不能被当成Container[Animal]使用这个问题一旦放进实际工程就会变得非常重要。因为它关系到 API 是否安全、扩展性是否好、类型检查器是否能帮你提前发现 bug。一、先建立直觉子类型关系不一定会自动传递到容器上假设我们有这样的类层次classEvent:passclassMouseEvent(Event):defclick_position(self)-tuple[int,int]:return(100,200)classKeyboardEvent(Event):defkey(self)-str:returnEnter很明显MouseEvent 是 Event 的子类型 KeyboardEvent 是 Event 的子类型那么问题来了list[MouseEvent]是list[Event]的子类型吗很多初学者会觉得“当然是啊MouseEvent 都是 EventMouseEvent 列表不就是 Event 列表吗”但答案是不是。为什么看下面这个例子defappend_keyboard_event(events:list[Event])-None:events.append(KeyboardEvent())mouse_events:list[MouseEvent][MouseEvent()]append_keyboard_event(mouse_events)# 假设允许这样做如果list[MouseEvent]可以传给list[Event]那么append_keyboard_event()就能往这个列表里塞入一个KeyboardEvent。这样一来mouse_events这个原本应该只包含MouseEvent的列表里面就混进了KeyboardEvent。后面如果代码这样写foreventinmouse_events:print(event.click_position())遇到KeyboardEvent时就会出错因为KeyboardEvent没有click_position()方法。这就是为什么 Python 的list[T]在类型系统里通常是不变的。二、三个概念一句话讲清楚我们先给出最核心的定义。假设MouseEvent是Event的子类MouseEvent:Event那么对于一个泛型类型Box[T]1. 协变子类型关系保持方向如果MouseEvent:Event并且可以推出Box[MouseEvent]:Box[Event]那么Box[T]对T是协变的。直觉只读、只产出 T 的接口通常可以协变。比如Sequence[MouseEvent]可以当成 Sequence[Event]因为你只能从里面读出元素不能随便往里面塞新的KeyboardEvent。2. 逆变子类型关系反过来如果MouseEvent:Event但可以推出Handler[Event]:Handler[MouseEvent]那么Handler[T]对T是逆变的。直觉只消费 T 的接口通常可以逆变。比如一个能处理所有Event的处理器当然也能处理MouseEvent。fromcollections.abcimportCallabledefhandle_any_event(event:Event)-None:print(handle event)defregister_mouse_handler(handler:Callable[[MouseEvent],None])-None:handler(MouseEvent())register_mouse_handler(handle_any_event)# 合理这里register_mouse_handler()需要的是“能处理 MouseEvent 的函数”。handle_any_event()能处理任何Event当然也能处理MouseEvent所以它可以传进去。这就是函数参数位置的逆变。3. 不变子类型关系不传递如果MouseEvent:Event但Box[MouseEvent]不是 Box[Event]Box[Event]也不是 Box[MouseEvent]那么Box[T]对T是不变的。直觉既读又写的可变容器通常是不变的。典型例子就是list[T]dict[K,V]set[T]它们都可以修改内容因此不能轻易协变。三、协变设计“只读集合接口”时最常见协变最适合出现在“生产者”或“只读视图”里。比如你在设计一个事件仓库只允许外部读取事件不允许修改内部集合fromtypingimportGeneric,TypeVar T_coTypeVar(T_co,covariantTrue)classReadOnlyEventStore(Generic[T_co]):def__init__(self,events:list[T_co])-None:self._eventseventsdefget_all(self)-tuple[T_co,...]:returntuple(self._events)deffirst(self)-T_co:returnself._events[0]这里T_co是协变的因为它只出现在返回值位置。现在我们可以这样使用defprint_events(store:ReadOnlyEventStore[Event])-None:foreventinstore.get_all():print(type(event).__name__)mouse_storeReadOnlyEventStore([MouseEvent(),MouseEvent()])print_events(mouse_store)# 类型上合理为什么合理因为print_events()只需要读取Event。而mouse_store里读出来的都是MouseEvent每一个MouseEvent都是Event所以安全。关键在于只读意味着外部不能往里面塞错误类型的对象。如果我们给ReadOnlyEventStore添加一个写方法就会破坏协变classBadStore(Generic[T_co]):defadd(self,event:T_co)-None:...这在类型检查器那里通常会被认为不安全因为协变类型变量不能随便出现在参数位置。工程经验是当你想让Repository[SubType]可以安全地传给需要Repository[BaseType]的地方时请优先设计只读接口。例如比起直接暴露list[MouseEvent]更好的公共接口通常是Sequence[MouseEvent]Iterable[MouseEvent]tuple[MouseEvent,...]因为它们表达的是“我给你数据但你不能改我的内部状态”。四、逆变回调函数和事件处理器的关键逆变最容易让人困惑但它在回调设计里非常自然。假设你在写一个 UI 框架允许用户注册鼠标事件处理器fromcollections.abcimportCallable MouseHandlerCallable[[MouseEvent],None]defregister_mouse_handler(handler:MouseHandler)-None:eventMouseEvent()handler(event)调用方可以传入这样一个函数defhandle_mouse(event:MouseEvent)-None:print(event.click_position())register_mouse_handler(handle_mouse)这当然没问题。但下面这个函数也应该被允许deflog_any_event(event:Event)-None:print(fevent:{type(event).__name__})register_mouse_handler(log_any_event)为什么因为框架承诺只会传入MouseEvent。而log_any_event()能接受任何Event自然也能接受MouseEvent。但是反过来就不行classDoubleClickEvent(MouseEvent):defclick_count(self)-int:return2defhandle_double_click(event:DoubleClickEvent)-None:print(event.click_count())register_mouse_handler(handle_double_click)# 不安全register_mouse_handler()只保证传入MouseEvent不保证一定是DoubleClickEvent。如果把只能处理DoubleClickEvent的函数注册进去当框架传入普通MouseEvent时函数内部调用click_count()就会出错。所以对于函数参数Callable[[T],None]T是逆变的。更口语化地说注册回调时能处理“更宽泛输入”的函数可以替代只能处理“更具体输入”的函数。这对事件系统、消息总线、插件机制特别重要。五、不变可变容器为什么最保守不变通常发生在“既读又写”的地方。比如defprocess_events(events:list[Event])-None:events.append(KeyboardEvent())如果允许你传入mouse_events:list[MouseEvent][MouseEvent()]process_events(mouse_events)就会破坏mouse_events的类型承诺。所以list[MouseEvent]不能当作list[Event]使用。正确做法是根据意图调整接口。如果函数只是读取fromcollections.abcimportSequencedefprint_event_names(events:Sequence[Event])-None:foreventinevents:print(type(event).__name__)那么你可以传入mouse_events:list[MouseEvent][MouseEvent()]print_event_names(mouse_events)因为Sequence是只读视角适合协变。如果函数确实要修改列表那么就应该明确接受list[Event]并且调用者也应该传入真正允许混合事件的列表events:list[Event][MouseEvent()]process_events(events)这不是类型系统在为难你而是在帮你把设计意图说清楚。六、一个实战案例设计事件处理器系统现在我们做一个更接近真实项目的例子。需求如下系统有多种事件可以注册事件处理器有些处理器只处理某类事件有些通用处理器可以处理所有事件事件列表对外只读避免外部破坏内部状态。先定义事件classEvent:defname(self)-str:returnself.__class__.__name__classUserLoginEvent(Event):def__init__(self,user_id:int)-None:self.user_iduser_idclassOrderCreatedEvent(Event):def__init__(self,order_id:int)-None:self.order_idorder_id定义只读事件流fromtypingimportGeneric,TypeVarfromcollections.abcimportIterable T_coTypeVar(T_co,boundEvent,covariantTrue)classEventStream(Generic[T_co]):def__init__(self,events:Iterable[T_co])-None:self._eventstuple(events)def__iter__(self):returniter(self._events)deffirst(self)-T_co:returnself._events[0]这里EventStream[T]是协变的。因为它只负责“产出事件”不负责“消费事件”。然后定义处理器协议fromtypingimportProtocol T_contraTypeVar(T_contra,boundEvent,contravariantTrue)classEventHandler(Protocol[T_contra]):defhandle(self,event:T_contra)-None:...这里EventHandler[T]是逆变的。因为它负责“消费事件”。实现两个处理器classLoggingHandler:defhandle(self,event:Event)-None:print(f[LOG]{event.name()})classLoginHandler:defhandle(self,event:UserLoginEvent)-None:print(fuser login:{event.user_id})现在我们写一个只处理登录事件的分发函数defdispatch_login_event(event:UserLoginEvent,handlers:Iterable[EventHandler[UserLoginEvent]],)-None:forhandlerinhandlers:handler.handle(event)使用login_eventUserLoginEvent(user_id42)handlers:list[EventHandler[UserLoginEvent]][LoggingHandler(),LoginHandler(),]dispatch_login_event(login_event,handlers)这里LoggingHandler的handle()接受的是Event比UserLoginEvent更宽泛所以它可以作为EventHandler[UserLoginEvent]使用。这就是逆变的价值。如果你在大型系统中设计消息处理、领域事件、插件机制、任务调度器、数据管道这种设计非常常见。七、用一张文字图理解三者可以把泛型接口分成三类类型变量 T 的使用位置 只返回 T不接收 T Producer[T] / ReadOnlyBox[T] | v 协变 Producer[Child] 可以当 Producer[Parent] 只接收 T不返回 T Consumer[T] / Handler[T] | v 逆变 Consumer[Parent] 可以当 Consumer[Child] 既接收 T又返回 T MutableBox[T] / list[T] | v 不变 MutableBox[Child] 和 MutableBox[Parent] 互不替代再简化成一句口诀读用协变写用逆变读写都有多半不变。当然这只是帮助理解的口诀不是机械规则。真实设计中还要看接口语义。八、常见误区不要把list当成万能参数类型很多 Python 代码喜欢这样写defsummarize(events:list[Event])-None:...如果这个函数只是遍历事件不修改列表那么这不是一个好签名。更好的写法是fromcollections.abcimportIterabledefsummarize(events:Iterable[Event])-None:foreventinevents:print(event.name())或者如果你需要支持索引、长度fromcollections.abcimportSequencedefsummarize(events:Sequence[Event])-None:print(len(events))print(events[0].name())这样做有三个好处第一调用者可以传入list、tuple、生成器、自定义集合。第二接口表达更准确我只是读不会改。第三类型系统更宽容、更安全Sequence[UserLoginEvent]可以传给Sequence[Event]。这就是高级工程师写 API 时经常强调的接收参数时尽量依赖抽象接口而不是具体可变实现。九、回调函数里的“反直觉”其实很合理再看一个回调例子fromcollections.abcimportCallabledefrun_login_pipeline(callback:Callable[[UserLoginEvent],None])-None:callback(UserLoginEvent(user_id1001))下面两个函数defcallback_for_event(event:Event)-None:print(event:,event.name())defcallback_for_login(event:UserLoginEvent)-None:print(login:,event.user_id)都可以传进去run_login_pipeline(callback_for_event)run_login_pipeline(callback_for_login)但这个不应该传进去classAdminLoginEvent(UserLoginEvent):defadmin_level(self)-int:return10defcallback_for_admin_login(event:AdminLoginEvent)-None:print(event.admin_level())run_login_pipeline(callback_for_admin_login)# 不安全因为run_login_pipeline()并不承诺传入AdminLoginEvent它只承诺传入UserLoginEvent。这也是为什么很多人刚学逆变时觉得绕我们习惯从“对象继承”角度思考但回调函数更应该从“调用方承诺”角度思考。谁调用函数谁就决定传入什么类型。一个函数能否作为回调取决于它能不能安全接住调用方传来的参数。十、最佳实践如何在 Python 项目中真正用起来1. 公共 API 尽量使用只读抽象如果函数不修改集合不要写defrender(items:list[Item])-None:...优先写fromcollections.abcimportSequencedefrender(items:Sequence[Item])-None:...或者fromcollections.abcimportIterabledefrender(items:Iterable[Item])-None:...这能让你的接口更灵活也更容易被类型系统接受。2. 回调参数要理解逆变设计事件注册函数时defregister_handler(handler:Callable[[UserLoginEvent],None])-None:...允许用户传入defhandle_any_event(event:Event)-None:...这是合理的不要因为“参数类型不完全一样”就误判它不安全。真正不安全的是只能处理更窄类型的函数。3. 可变容器不要强行协变如果你真的需要修改集合就诚实地写defadd_event(events:list[Event])-None:events.append(Event())然后调用者应该传入events:list[Event][]不要试图让list[MouseEvent]兼容list[Event]。这不是类型检查器保守而是避免真实 bug。4. 自定义泛型时先问自己“它是生产者还是消费者”当你写classRepository(Generic[T]):...请立刻问自己这个Repository[T]是只返回Tdefget(self,id:int)-T:...那它可能适合协变。它是只接收Tdefsave(self,item:T)-None:...那它可能适合逆变。它既接收又返回defget(self,id:int)-T:...defsave(self,item:T)-None:...那它大概率应该保持不变。很多仓储接口之所以难以设计就是因为它同时承担了读取和写入两种职责。此时可以考虑拆分接口T_coTypeVar(T_co,covariantTrue)T_contraTypeVar(T_contra,contravariantTrue)classReader(Protocol[T_co]):defget(self,id:int)-T_co:...classWriter(Protocol[T_contra]):defsave(self,item:T_contra)-None:...这样比一个巨大而模糊的Repository[T]更清晰也更符合接口隔离原则。十一、高级工程师为什么必须理解这个因为协变、逆变、不变真正影响的不是“类型写得漂不漂亮”而是系统设计质量。第一它帮助你设计更稳定的 API一个好的 API 不只是“能跑”还应该清楚表达边界。Sequence[Event]表达的是我只读。list[Event]表达的是我可能会改。Callable[[UserLoginEvent],None]表达的是我会传给你一个登录事件你要能处理它。类型标注不是装饰品它是接口契约。第二它让类型检查器帮你挡住真实 bug在动态语言里很多错误会在运行时才暴露。比如把只支持AdminLoginEvent的函数注册到普通登录事件处理器里代码可能跑到某个分支才炸。类型检查器能提前告诉你这个回调不能安全处理 UserLoginEvent这不是“类型洁癖”而是把线上事故提前挪到开发阶段。第三它让团队协作成本更低大型项目里代码不是写给机器看的也是写给同事看的。当你写下defconsume(events:Iterable[Event])-None:...别人会知道你只是消费这个事件流不会修改它。当你写下defmutate(events:list[Event])-None:...别人会警觉这个函数可能会改变传入列表。清晰的类型签名就是团队之间的低成本沟通。第四它让框架和 SDK 更容易扩展框架作者经常要处理这些问题用户能不能传入更通用的处理器插件能不能返回更具体的结果只读数据源能不能支持子类型数据这些问题背后都是协变、逆变、不变。如果你不理解它很容易写出过度严格或过度宽松的接口。过度严格会让用户很难用。过度宽松会让系统不安全。高级工程师的价值就在于能在灵活性和安全性之间找到平衡。十二、一个实用判断清单以后看到泛型类型X[T]可以按下面方式判断1. X[T] 只返回 T不接收 T 是考虑协变。 2. X[T] 只接收 T不返回 T 是考虑逆变。 3. X[T] 既接收 T又返回 T 是优先不变。 4. X[T] 是可变集合 是大概率不变。 5. X[T] 是只读集合 是大概率协变。 6. X[T] 是回调、处理器、消费者 是重点关注逆变。对应到 Python 常见场景Sequence[T] 协变 Iterable[T] 协变 tuple[T, ...] 协变 Callable[[T], R] 参数 T 逆变返回 R 协变 list[T] 不变 dict[K, V] 通常不变 set[T] 通常不变十三、结语类型不是束缚而是设计语言Python 的魅力在于它简单、灵活、富有表达力。你可以用它写一个十行脚本也可以用它构建复杂的 Web 系统、数据平台、机器学习管道和自动化基础设施。但随着项目变大真正考验工程能力的不再只是“会不会写语法”而是你能不能设计出清晰的边界你能不能让代码在变化中保持稳定你能不能让团队成员一眼看懂你的意图协变、逆变、不变表面上是类型系统概念背后却是 API 设计、数据流方向、职责边界和工程安全。所以不要把它们当成晦涩的“类型体操”。把它们看成三种设计信号协变我只生产你放心读取。 逆变我只消费你放心交给我。 不变我既读又写请不要随便替换。当你真正理解这一点就会发现类型标注不再是负担而是一种温柔的约束。它不会限制 Python 的自由反而会让自由更可靠。最后留给你两个问题你在项目中有没有遇到过list[Child]不能传给list[Parent]的困惑你设计过事件处理器、回调函数或插件系统吗如果重新设计一次你会如何使用协变、逆变和不变来表达接口边界