抽象基类（abc）不可替代，因其通过@abstractmethod在实例化时强制校验方法实现，提前暴露设计缺陷；而普通父类仅靠空方法无法阻止未实现子类被创建，导致运行时错误难定位。
为什么不能直接用普通父类定义接口
普通父类可以写空方法，但子类继承后不实现也不会报错——直到运行时调用才 AttributeError。这种延迟暴露的问题在大型项目里很难定位，尤其当接口被多个团队协作实现时，容易漏掉关键方法或参数签名不一致。
抽象基类则不同：ABC + @abstractmethod 会在你尝试实例化未完整实现的子类时立刻抛出 TypeError: Can't instantiate abstract class ... with abstract method ...，把问题卡在构造阶段，而不是等数据流跑通一半再崩。
- 普通父类：靠文档、靠约定、靠人盯，容易失效
-
ABC：靠解释器强制校验，不妥协、不绕过、不静默忽略 - 类型检查工具（如 mypy）也能识别
@abstractmethod，提前标红未实现的方法
为什么不用鸭子类型而要加 ABC
鸭子类型本身没问题，isinstance(obj, collections.abc.Iterable) 这类检查也常用。但纯鸭子类型缺乏“可验证契约”——你无法确认一个对象是否 *有意图地* 实现了某组语义一致的方法（比如 read() 和 write() 是否成对支持、参数是否可互换）。
ABC 把鸭子类型从“运行时试探”升级为“结构化协议”：
- 显式声明“这个类承诺支持哪些行为”，不是靠猜
- 支持
register()注册已有类（比如str或tuple）为虚拟子类，不改源码也能通过isinstance() - 第三方库（如
typing）能基于 ABC 做更精准的类型提示，例如def process(data: SupportsRead)
ABC 的 register() 和 __subclasshook__ 是干什么的
这是 ABC 区别于 Java/C# 接口的关键弹性点：它不强制继承关系。比如你有个现成的 requests.Response 类，不想动它的源码，但想让它被当成某种自定义协议 DataSource 使用，就可以用 DataSource.register(requests.Response)。
更进一步，__subclasshook__ 允许你自定义“什么算子类”的逻辑——比如只要一个类有 .data 属性和 .status_code 方法，就自动视为 DataSource 的子类，无需注册或继承。
-
register()：手动打标签，适合已知类 -
__subclasshook__：自动识别，适合动态判断行为特征 - 二者都让
isinstance()和issubclass()生效，但不会污染 MRO，也不提供父类方法继承
内置 collections.abc 里的 ABC 怎么用
别自己造轮子。Python 标准库的 collections.abc 已经提供了经过充分验证的接口定义，比如 Iterable、Mapping、Sized、Callable 等。它们不是示例代码，而是正式协议。
直接拿来用，既能获得类型提示支持，又能保证与内置函数（如 len()、for ... in）兼容：
- 想让自定义容器支持
len(obj)？继承collections.abc.Sized并实现__len__ - 想让对象能被
for遍历？继承collections.abc.Iterable并实现__iter__ - 用
isinstance(obj, collections.abc.Mapping)比hasattr(obj, '__getitem__')更可靠，因为它还检查了其他必要方法
真正容易被忽略的是：这些内置 ABC 的协议细节（比如 Mapping 要求同时实现 __getitem__、__iter__、__len__）必须全部满足，少一个 isinstance() 就返回 False——这不是 bug，是设计意图。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
