优先使用组合而非继承，因其更灵活、易维护、耦合低；组合体现“has-a”关系，支持运行时替换组件、简化测试扩展，并契合python鸭子类型与显式哲学。
在Python中，优先使用组合而非继承，是更灵活、更易维护的设计选择。继承容易导致类之间耦合过紧，而组合让对象职责清晰、复用性更强，也更符合Python的“显式优于隐式”和“简单优于复杂”的哲学。
组合让关系更明确
组合体现的是“has-a”（拥有）关系，比如“汽车有一个引擎”，而不是“汽车是一种引擎”。这种语义更贴近现实，代码读起来也更自然。
- 用实例变量引用其他对象，而不是通过class A(B)去继承
- 被组合的对象可以随时替换（如换不同型号引擎），无需改动主类结构
- 避免了多层继承带来的方法解析顺序（MRO）困惑
组合更容易测试和扩展
当你把功能拆成独立的小类，每个类只做一件事，就很容易单独单元测试。要新增行为时，只需添加新组件，或调整组合方式，不用动原有类的继承链。
- 例如日志功能，可写一个Logger类，再由业务类持有一个logger实例，而不是让所有业务类都继承自某个Loggable基类
- 运行时可动态切换策略：比如把FileLogger换成DBLogger，只要接口一致，主逻辑完全无感
Python本身对组合支持友好
Python没有严格的访问控制（如private），也没有抽象基类强制要求，这让组合实现非常轻量。你不需要定义一堆接口或模板方法，直接传入对象、调用方法即可。
- 利用鸭子类型：只要对象有.save()方法，就能作为存储组件传入
- __getattr__或functools.partial还能进一步简化委托逻辑
- 标准库中大量使用组合，比如Threading.Thread接受target函数，而不是让你继承它来重写run
继承不是不能用，但要有意识地选
继承适合表达“is-a”且契约稳定的关系，比如int是numbers.Real的一种。但多数业务场景里，“能用”不等于“该用”。
- 如果只是为了复用代码而继承，大概率该用组合+委托
- 如果基类方法可能被子类随意覆盖，又没文档约束行为，那继承反而增加理解成本
- 不确定要不要继承时，先尝试组合；发现重复代码太多、又高度相关，再考虑提取为基类