ABC 不是多此一举，而是防错刚需：它将“漏实现方法”的错误提前到实例化时抛出 TypeError，避免运行时 AttributeError；通过 ABCMeta 元类强制校验抽象方法，确保子类必须覆盖全部 @abstractmethod，且装饰器顺序必须为 @abstractmethod 在最内层。
为什么 ABC 不是“多此一举”，而是防错刚需
因为 Python 动态特性太强，isinstance(obj, SomeInterface) 会静默失败、obj.do_something() 到运行时才报 AttributeError——而 ABC 能把这类错误提前到实例化那一刻。它不是为了“看起来更面向对象”，而是让“漏实现方法”这种低级但高频的错误，变成无法绕过的 TypeError: Can't instantiate abstract class ...。
- 没用
ABC：调用链走到第 5 层才发现某个子类忘了写save()，堆栈深、定位难 - 用了
ABC：一 new 实例就崩，错误位置精准到类定义行 - IDE 和类型检查器（如 mypy）能基于
ABC做准确补全和参数提示，普通基类做不到
ABC 和普通基类的关键区别在哪
普通基类可以被实例化，抽象方法只是“建议实现”；ABC 是带校验的契约：只要有一个 @abstractmethod，整个类就不可实例化，且子类必须覆盖全部抽象方法，否则子类也自动变成抽象类。
- 继承
ABC是声明“我只定义接口，不提供默认行为” - 继承普通类 +
pass方法，只是“我懒得写”，Python 完全不管子类是否覆盖 -
abc.ABC底层用的是ABCMeta元类，它在class语句执行完后立刻扫描，不等你调用__init__
什么时候该用 ABC，而不是协议（Protocol）或鸭子类型
选 ABC 的典型场景是：你需要强制约束、需要运行时类型检查、或者要给子类提供可复用的默认逻辑。
- 需要
isinstance(x, Drawable)返回True？→ 用ABC（Protocol不参与运行时检查） - 多个子类共享
log_operation()默认实现？→ 用ABC（Protocol只能声明，不能实现） - 只是临时想表达“有
read()和close()就算文件类”？→ 用Protocol更轻量 - 连
Protocol都嫌重，纯靠文档约定？→ 鸭子类型，但风险自担
最容易被忽略的坑：@abstractmethod 的装饰顺序和组合
@abstractmethod 必须是最内层装饰器，否则元类扫描不到——这是新手最常踩的隐形雷。
立即学习“Python免费学习笔记（深入）”；
- ✅ 正确：
@property外面包一层@abstractmethod→@abstractmethod @property - ❌ 错误：
@property包着@abstractmethod→@property @abstractmethod（会被当成普通 property，不触发检查） - 类方法同理：
@classmethod @abstractmethod✅，@abstractmethod @classmethod❌ - 如果子类实现了方法但拼错了名（比如
get_data()写成get_date()），照样报错——ABC校验的是方法签名，不是逻辑
真正难的不是写 ABC，而是判断哪些契约值得上升为抽象基类：太细，约束过重；太粗，形同虚设。一个实用经验是——当你发现自己在三个以上地方写“请确保子类实现 XXX”，那就该把它收进 ABC 了。
