引入Protocol类后，抽象基类是否已冗余？

一、Protocol相对ABC的劣势 #

• 运行时校验缺失：Protocol默认仅作用于静态类型检查（比如mypy），运行时不会验证类是否符合协议要求；除非添加@runtime_checkable装饰器，否则无法在运行时发现不符合的情况。而ABC只要子类继承了，运行时就会强制检查抽象方法是否实现，没实现直接报错。
• 易出现意外匹配：Protocol基于结构子类型，只要类的方法/属性签名匹配就会被认为符合协议，哪怕两个类完全无关。这种“隐式匹配”有时候会导致类型检查误判，而ABC通过显式继承关系避免了这个问题。
• 版本兼容性差：Protocol是Python 3.8才引入的特性，如果你的代码需要兼容3.8之前的版本，ABC是更稳妥的选择。

二、性能损耗问题 #

• 常规使用无损耗：仅用于静态类型检查的Protocol，完全不会带来运行时性能开销——Python解释器运行时会忽略类型注解，所有检查都在开发阶段由类型检查工具完成。
• 启用运行时检查有轻微开销：如果给Protocol加上@runtime_checkable，运行时会额外验证类的结构，这会带来少量性能损耗，但除非是超高频调用的场景，否则基本可以忽略。ABC的运行时检查仅在子类继承和实例化时触发，后续调用和普通类无异。

三、ABC仍是最优选择的场景 #

• 需要运行时强制约束：如果你必须确保所有子类在运行时就实现了指定方法/属性，而不是只在静态检查阶段发现问题，ABC的强制校验更直接，无需额外配置。
• 需明确的继承关系标识：当你希望子类通过显式继承来表明归属（比如框架的插件类、组件基类），用ABC可以通过isinstance()或issubclass()清晰判断类型，避免结构匹配带来的模糊性。
• 兼容旧Python版本：针对3.8之前的Python环境，ABC是唯一的抽象类实现方案。
• 需要抽象成员的默认实现：ABC允许给抽象方法编写默认实现，子类可以选择重写或直接使用；Protocol虽然能定义方法签名，但默认没有运行时层面的默认实现机制。
• 需注册虚拟子类：通过ABC的register()方法，可以将无关类注册为其子类，既能实现类似鸭子类型的灵活性，又能被isinstance()识别——这一点是未启用运行时检查的Protocol做不到的。

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