答案：Python的协议（Protocol）通过结构化子类型实现接口兼容性，抽象基类（ABC）通过继承和运行时检查强制接口实现。Protocol侧重静态类型检查下的“能做什么”，ABC强调运行时的“必须做什么”与类层次结构，二者互补，分别适用于灵活集成与严格契约场景。
Python的协议（Protocol）和抽象基类（ABC）本质上都是为了在Python这个动态类型语言中引入更强的“接口”概念，帮助我们定义和验证对象行为。简单来说，协议侧重于“结构匹配”，即只要你的对象有我需要的方法和属性，那它就是符合这个协议的；而抽象基类则更侧重于“继承关系”，它强制子类实现某些方法，是一种更显式的类型契约。两者都在提升代码可维护性和可读性上发挥作用，但应对的场景和哲学有所不同。
解决方案
理解Python的协议和抽象基类，关键在于把握它们各自解决的问题和实现机制。它们并非互斥，而是互补的工具，旨在为Python的“鸭子类型”哲学提供更坚实的基础，特别是在大型项目或需要严格类型检查的场景下。
协议，特别是通过
typing.Protocol引入的，是Python类型提示系统的一部分。它允许我们定义一个接口，而无需强制任何类去显式继承它。只要一个类或对象实现了协议中定义的所有方法和属性，它就被认为是符合该协议的。这与传统的静态语言接口概念非常接近，但又保留了Python的灵活性，即“如果它走起来像鸭子，叫起来像鸭子，那么它就是鸭子”。Protocol在此基础上，加入了类型检查器在静态分析时就能验证“这只鸭子”是否真的拥有“走”和“叫”的能力。
抽象基类（ABC），则通过
abc模块实现，它提供了一种在运行时强制执行接口契约的方式。一个ABC可以声明抽象方法，任何继承自该ABC的非抽象子类都必须实现这些抽象方法，否则在实例化时会抛出
TypeError。ABC更像是一种传统的面向对象设计模式，用于构建清晰的类层次结构，并确保子类提供特定的行为。它不仅仅是类型检查的工具，更是一种运行时行为的约束。
立即学习“Python免费学习笔记（深入）”；
在我看来，选择使用哪种机制，很大程度上取决于你对“契约”的期望是静态检查层面的“结构兼容性”，还是运行时强制的“继承关系”。
Python协议（typing.Protocol
）如何实现结构化类型？
typing.Protocol是在 PEP 544 中引入的，它的核心思想是“结构化子类型化”（Structural Subtyping）。这意味着，一个类是否符合某个协议，不是看它是否显式声明继承了该协议，而是看它是否“结构上”满足了协议定义的要求——即它是否拥有协议中声明的所有方法和属性，并且这些方法和属性的签名（参数类型、返回类型）也匹配。这就像是给“鸭子类型”穿上了一件类型提示的外衣，让类型检查工具（比如 MyPy）能在代码运行前就发现潜在的类型不匹配问题。
举个例子，假设我们想定义一个“可保存”的接口，任何能保存自身状态的对象都应该符合这个接口。
from typing import Protocol
class Savable(Protocol):
def save(self, path: str) -> None:
"""将对象状态保存到指定路径。"""
... # 协议中不需要实现具体逻辑，只定义签名
@property
def name(self) -> str:
"""对象的名称。"""
...
class MyData:
def __init__(self, data_name: str, content: str):
self._name = data_name
self._content = content
def save(self, path: str) -> None:
print(f"Saving {self._name} content to {path}...")
with open(path, 'w') as f:
f.write(self._content)
@property
def name(self) -> str:
return self._name
class AnotherObject:
def process(self):
print("Processing...")
def process_savable_item(item: Savable):
print(f"Processing savable item: {item.name}")
item.save("output.txt")
# MyData 并没有显式继承 Savable，但它结构上符合
data_instance = MyData("Report", "This is a detailed report.")
process_savable_item(data_instance) # MyPy 会认为这是合法的
# another_instance 不符合 Savable 协议
another_instance = AnotherObject()
# process_savable_item(another_instance) # MyPy 会在这里报错从代码中能看出，
MyData类并没有写
class MyData(Savable):，但因为它实现了
save方法和
name属性，并且签名匹配，MyPy 这样的类型检查器就会认为
MyData对象是
Savable类型的一个有效实例。这提供了一种非常灵活的接口定义方式，特别适合于那些你无法控制其父类的第三方库对象，或者当你只是想表达一个“能力”而不是一个严格的“is-a”关系时。我个人觉得，Protocol 极大地提升了 Python 在大型项目中进行类型安全编程的体验，它让“鸭子类型”的优点得以保留，同时又避免了其潜在的运行时错误。
抽象基类（ABC）在运行时如何强制接口实现？
抽象基类（ABC）则是一种更传统的接口实现方式，它通过
abc模块提供。ABC 的核心在于它允许你定义一个类，其中包含一个或多个抽象方法。任何尝试实例化该 ABC 的子类，如果它没有实现所有这些抽象方法，Python 解释器就会在运行时抛出
TypeError。这是一种非常强烈的契约，确保了继承体系中的类型安全和行为一致性。
ABC 的实现通常涉及到
ABCMeta元类和
@abstractmethod装饰器。
import abc
class Document(abc.ABC):
@abc.abstractmethod
def load(self, path: str) -> None:
"""加载文档内容。"""
pass
@abc.abstractmethod
def save(self, path: str) -> None:
"""保存文档内容。"""
pass
def get_summary(self) -> str:
"""提供一个默认的摘要方法，子类可以选择覆盖。"""
return "No summary available."
class TextDocument(Document):
def __init__(self):
self._content = ""
def load(self, path: str) -> None:
print(f"Loading text from {path}...")
with open(path, 'r') as f:
self._content = f.read()
def save(self, path: str) -> None:
print(f"Saving text to {path}...")
with open(path, 'w') as f:
f.write(self._content)
def get_summary(self) -> str:
return f"Text document with {len(self._content)} characters."
class ImageDocument(Document):
# 故意不实现 save 方法
def load(self, path: str) -> None:
print(f"Loading image from {path} (simulated)...")
# doc = Document() # 尝试实例化抽象基类会报错：TypeError: Can't instantiate abstract class Document with abstract methods load, save
text_doc = TextDocument()
text_doc.load("input.txt")
text_doc.save("output_text.txt")
print(text_doc.get_summary())
# image_doc = ImageDocument() # 尝试实例化 ImageDocument 会报错：
# TypeError: Can't instantiate abstract class ImageDocument with abstract methods save在这个例子中，
Document是一个抽象基类，它强制任何非抽象子类都必须实现
load和
save方法。
TextDocument成功实现了这两个方法，所以它可以被实例化。而
ImageDocument因为缺少
save方法的实现，试图实例化它时就会立即报错。这种机制在构建插件系统、框架或者任何需要确保特定行为的类层次结构时非常有用。它提供了一种运行时保障，确保了所有遵循此契约的子类都具备了核心功能。
ABC 还有
register方法，允许我们将一个不继承自 ABC 的类注册为 ABC 的“虚拟子类”。这样，
isinstance()和
issubclass()检查会认为该类是 ABC 的子类，即使它在类定义时没有显式继承。但这并不会强制该类实现抽象方法，它主要用于类型检查和运行时反射。我常常觉得
register就像是一种“后门”，让你可以将一些历史遗留或第三方类纳入你的类型体系中，而无需修改它们的源代码。
何时选择协议（Protocol），何时选择抽象基类（ABC）？
选择协议还是抽象基类，这真的取决于你的设计意图和上下文需求。在我多年的编程实践中，我总结出了一些经验，这两种工具各有其最佳应用场景。
选择协议（typing.Protocol
）的场景：
- 结构化子类型化和鸭子类型优先： 当你更关心一个对象“能做什么”而不是它“是什么类型”时，Protocol 是理想选择。你不需要强制继承关系，只要对象提供了所需的方法和属性即可。这在处理来自不同来源、但具有相似行为的对象时特别有用。
- 与现有类或第三方库集成： 当你想要为不属于你控制的类（比如来自第三方库的类）定义一个接口时，Protocol 是唯一实用的选择。你不能修改它们的源代码让它们继承你的 ABC，但你可以定义一个 Protocol，然后类型检查器会根据这些类的结构来判断它们是否符合你的接口。
- 轻量级接口定义： 当你只需要一个简单的行为契约，而不需要复杂的类层次结构或运行时强制时，Protocol 更简洁。它主要是为静态类型检查服务的。
- Ad-hoc 接口： 很多时候，你可能只是为了一个特定函数或方法定义一个临时的、局部的接口，Protocol 在这种情况下显得非常自然和灵活。
选择抽象基类（abc.ABC
）的场景：
- 强制运行时契约： 当你需要确保所有继承自某个基类的子类都必须实现特定的方法时，ABC 是不可替代的。它在实例化时提供运行时检查，防止不完整的子类被创建。这对于构建框架、插件系统或需要严格一致行为的组件至关重要。
- 构建明确的类层次结构： 当你的设计涉及到清晰的“is-a”关系，并且你希望通过继承来共享部分实现或提供默认行为时，ABC 是一个很好的选择。它可以作为一系列相关类的共同祖先，定义它们的公共接口和（可选的）部分实现。
- 提供默认实现或模板方法： ABC 允许你实现非抽象方法，为子类提供默认行为或定义模板方法模式，而协议则完全是关于接口定义，不包含任何实现。
-
isinstance()
和issubclass()
检查的语义化： 如果你希望通过isinstance()
或issubclass()
来检查一个对象是否属于某个抽象类型家族，并且这个检查需要在运行时有明确的语义，ABC 更适合。特别是结合register
方法，可以灵活地扩展类型检查范围。
总的来说，如果你主要是想利用 Python 的类型提示系统在开发阶段捕获错误，并且偏爱灵活的结构化类型，那么 Protocol 可能是你的首选。但如果你需要一个强有力的运行时保证，确保子类必须遵守某个契约，并且你正在设计一个明确的类继承体系，那么 ABC 则是更合适的工具。在某些复杂的场景下，你甚至可能会发现它们可以协同工作，比如一个 ABC 声明了抽象方法，而一个 Protocol 进一步细化了这些方法的具体行为，提供更细粒度的类型提示。这两种机制都是 Python 应对复杂系统设计挑战的有力武器，理解它们的异同，能帮助我们写出更健壮、更易维护的代码。
