本文详解 python 类型系统中 protocol 与泛型 typevar 的协变（covariant）、逆变（contravariant）和不变（invariant）行为，结合 pep 544 规范与主流类型检查器（mypy/pycharm）的实际表现，厘清常见误判根源，并提供可验证的代码示例与规避建议。
本文详解 python 类型系统中 protocol 与泛型 typevar 的协变（covariant）、逆变（contravariant）和不变（invariant）行为，结合 pep 544 规范与主流类型检查器（mypy/pycharm）的实际表现，厘清常见误判根源，并提供可验证的代码示例与规避建议。
在 Python 的结构化类型系统中，Protocol 是实现静态鸭子类型的核心机制（PEP 544），它不依赖继承关系，而通过方法签名的结构性匹配来判定兼容性。当协议与泛型（TypeVar）结合使用时，类型方差（variance）决定了泛型参数在子类型关系中的传播规则——这是类型安全的关键，却也是最容易被误解的部分。
? 方差本质：由使用位置决定方向
Python 中 TypeVar 的方差并非由声明本身“决定”，而是由其在协议方法中的使用位置（parameter vs. return type）和语义角色（输入 vs. 输出）共同推导得出。PEP 544 明确规定：
-
返回类型位置（output）天然协变：若
T_co出现在-> T_co中，则DogAdopter（返回Dog）可安全赋值给Adopter[Animal]（期望返回Animal），因为Dog是Animal的子类，向上转型安全。 -
参数类型位置（input）天然逆变：若
T_contra出现在(animal: T_contra)中，则AnimalWalker（接受Animal）应能赋值给Walker[Dog]（要求接受Dog），因为能处理更宽泛的Animal，必然也能处理其子类Dog（“宽进窄出”原则）。 -
双向使用（如
Feeder[T]中既作参数又作返回值）强制不变（invariant）：此时T在同一协议中既是输入又是输出，无法保证单一方向的安全性，故Feeder[Dog]与Feeder[Animal]互不兼容。
⚠️ 常见误区解析：为什么你的测试结果“反直觉”？
你观察到的 feeder3: Feeder[Animal] = DogFeeder() 通过检查，表面合理但实质违反不变性规范——这并非 Python 类型系统的本意，而是当前部分类型检查器（如 PyCharm 内置检查器或旧版 mypy）对协议方差推导的不完整实现。
严格按 PEP 544，Feeder[T] 因 feed(self, animal: T) -> T 同时含 T 于参数与返回值，必须视为不变。因此：
- ✅
Feeder[Dog] = DogFeeder()（精确匹配） - ❌
Feeder[Dog] = AnimalFeeder()（AnimalFeeder.feed参数接受Animal，但Feeder[Dog]要求只能传Dog；返回Animal也不满足-> Dog） - ❌
Feeder[Animal] = DogFeeder()（DogFeeder.feed参数只接受Dog，但Feeder[Animal]允许传任意Animal，如Cat()将导致运行时错误）
类似地，walker2: Walker[Dog] = AnimalWalker() 失败，恰恰暴露了工具链的方差支持不足：Walker[T_contra] 明确声明逆变，AnimalWalker.walk(animal: Animal) 应完全满足 Walker[Dog] 对 walk(animal: Dog) 的要求（因 Animal 可接收 Dog 实例）。该检查失败说明当前环境未充分实现逆变协议的结构匹配。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
✅ 验证与最佳实践：用 mypy 确认规范行为
为获得符合 PEP 544 的权威判断，推荐使用最新版 mypy（≥1.10）进行验证。以下为可运行的最小验证脚本：
立即学习“Python免费学习笔记（深入）”；
# variance_demo.py
from typing import TypeVar, Protocol
class Animal: pass
class Dog(Animal): pass
# 不变协议（双向使用 T）
class Feeder(Protocol):
def feed(self, animal: Animal) -> Animal: ... # 显式写死类型，避免泛型歧义
# 协变协议（仅返回 T_co）
class Adopter(Protocol):
def adopt(self) -> Animal: ... # 协变：返回 Animal 的实现可赋给 Adopter[Dog]
# 逆变协议（仅参数 T_contra）
class Walker(Protocol):
def walk(self, animal: Animal) -> None: ... # 逆变：接受 Animal 的实现可赋给 Walker[Dog]
# 实现类
class DogFeeder:
def feed(self, animal: Dog) -> Dog: ... # ❌ 违反 Feeder 协议（需 Animal）
class AnimalAdopter:
def adopt(self) -> Animal: return Animal() # ✅ 满足 Adopter[Dog]（协变）
class AnimalWalker:
def walk(self, animal: Animal) -> None: ... # ✅ 满足 Walker[Dog]（逆变）
# 类型检查（运行 mypy variance_demo.py）
feeder: Feeder = DogFeeder() # mypy 报错：参数/返回类型不匹配
adopter: Adopter = AnimalAdopter() # ✅ 通过
walker: Walker = AnimalWalker() # ✅ 通过? 提示：在真实项目中，优先显式声明协议方法签名的具体类型（如
Animal），而非过度依赖泛型方差。这既提升可读性，也规避类型检查器差异带来的不确定性。若必须使用泛型，请以mypy为准，并在pyproject.toml中启用严格模式：[tool.mypy] strict = true disallow_untyped_defs = true
? 总结
- Python 协议的方差由
TypeVar在方法签名中的使用位置决定：返回值 → 协变，参数 → 逆变，双向 → 不变。 - 当前 PyCharm 等 IDE 的类型检查器对逆变/协变协议的支持尚不完善，
mypy是验证 PEP 544 合规性的黄金标准。 - 生产代码中，应避免在不变协议中混用泛型参数于输入/输出位置；对关键接口，采用具体类型声明比依赖方差推导更稳健、更易维护。
- 记住核心原则：协变用于“产出”（out），逆变用于“消耗”（in），不变用于“双向交互” —— 这是所有静态类型语言方差设计的通用基石。
