为什么Python的Protocol实现类通常不需要继承Protocol类？

不采用显式继承Protocol的写法有明确的合理依据，也符合Python社区的通用开发惯例，核心原因和Protocol的设计初衷、子类型实现逻辑有关：

1. 违背Protocol的核心设计目标 #

Protocol的本质是结构化子类型（静态化的鸭子类型），和ABC这类名义子类型的设计逻辑完全不同：它允许任意具备对应属性/方法的类自动满足Protocol的类型约束，不需要修改类的继承链。
最典型的场景就是适配第三方库类：假设第三方库有个类刚好实现了do_something方法，你不需要修改第三方代码给它加继承，就能直接把它传入接受MyProtocol类型参数的函数。如果所有实现都要求显式继承Protocol，就完全浪费了这个核心优势，等同于把Protocol用成了普通的抽象基类。

2. 可能引入非预期的运行时行为 #

默认情况下，Protocol里定义的方法是普通Python方法，如果你显式继承了Protocol但没有重写对应的方法：

• 静态类型检查器会正常报缺失实现的错误
• 但运行时会直接调用Protocol里的方法实现，如果你在Protocol的方法里只写了文档没有实际逻辑，就会出现非预期的行为。
  而隐式实现的类完全不会继承Protocol的任何方法和属性，不存在这类风险。

3. 社区通用惯例的选择 #

绝大多数Python项目、官方文档、PEP示例中，Protocol的实现默认都是隐式的，也就是常见的第一种写法：

class MyProtocol(Protocol):
    def do_something(self):
        """
        this should be doing something
        """

class ProtocolImplementation:
    def do_something(self):
        print("I am actually doing something.")

def consume_my_protocol(arg: MyProtocol):
    arg.do_something()

只有两种场景会推荐用显式继承的写法：

• 你需要明确标记某个类是专门为实现该Protocol设计的，给后续维护的开发者传递明确的语义
• 你需要用到运行时类型检查（比如isinstance(obj, MyProtocol)），且给Protocol加了@runtime_checkable装饰器，显式继承可以保证运行时检查的结果符合预期

总结 #

两种写法本身都没有语法错误，如果你确定需要显式标记实现关系，完全可以用显式继承的写法，它不属于反模式；但如果没有明确的特殊需求，默认采用隐式实现的写法更符合Protocol的设计意图，也更符合社区惯例。

内容的提问来源于stack exchange，提问作者IVlad