组合优于继承，因继承易引发隐性债务、mro混乱和参数不兼容等问题，而组合通过显式委托实现高内聚、低耦合、易测试与动态替换。
Python里
class A(B)不是万能钥匙
继承在Python中确实能快速复用代码，但一旦进入生产环境，class A(B)就容易变成“隐性债务”。它把子类和父类的实现细节强行绑在一起——比如父类某次重构改了<strong>init</strong>签名，所有子类都得跟着动；又或者父类加了个super().setup()调用，而某个子类忘了在自己的setup()里补上super()，运行时直接抛AttributeError。
更麻烦的是MRO（Method Resolution Order）问题。当多个父类存在同名方法，或出现菱形继承（如C(A, B)且A、B都继承D），Python靠C3算法算出调用顺序，但这个顺序不是直觉能猜出来的。C.mro()输出可能让人困惑，线上出错时排查成本远高于写几行委托代码。
常见错误现象包括：
- TypeError: __init__() takes 2 positional arguments but 3 were given（父类__init__参数变更未同步）
- 方法被意外跳过（MRO中靠前的类覆盖了本该执行的逻辑）
- 单元测试通过，集成后行为异常（因继承链中某层悄悄修改了状态）
用self.engine = Engine()代替class Car(Engine)
组合的核心动作就一句：self.xxx = SomeClass()，然后在方法里显式委托调用。它天然支持“运行时替换”，比如测试时传入FakeEngine()，上线后换回RealEngine()，完全不碰主类结构。
这种写法让依赖关系一目了然：Car类头部就能看到它“拥有”什么，而不是翻三页代码才搞清它“是”什么。也避免了单继承限制——Python只允许一个class语句指定父类，但你可以同时持有self.logger、self.validator、self.cache三个不同职责的对象。
使用场景举例： - 需要动态切换策略（如支付方式：PayPal vs Stripe） - 多个模块需独立演进（日志组件升级不影响核心业务逻辑） - 第三方库类不能修改，但你想复用其能力（包装而非继承）
super()不是银弹，self.delegate.method()才是可控开关
super()看似优雅，实则把控制权交给了Python的MRO机制。它在多重继承或框架钩子（如Django Model的save()）中尤其危险——你无法100%确认super().save()到底调了谁、何时调、是否已执行关键副作用。
而组合下的调用是确定的：self.db.save()就是self.db实例的save()，不会拐弯抹角。如果db对象本身也用了组合，那整条链路都是可读、可测、可mock的。
参数差异注意点：
- 继承：子类__init__必须兼容父类签名，否则super().__init__()会炸
- 组合：构造函数参数自由设计，__init__(self, db: DB, logger: Logger)清晰表达契约
多继承在生产环境基本等于自找麻烦
Python支持多继承，但生产代码里几乎没人真用。它放大了MRO不可预测性、方法冲突、初始化顺序混乱等问题。哪怕只是混入一个Mixin，也可能因为super()链断裂导致资源没释放、钩子没触发。
组合天然规避这个问题：想加功能？加个字段+几行委托就行。想删功能？删字段+删对应调用即可。没有“父类要不要重写<strong>del</strong>”、“Mixin该放MRO第几位”这种烧脑题。
容易踩的坑：
- 把组合写成“假继承”：def save(self): return self.db.save()写了一百遍，却不抽成通用委托基类
- 忘记生命周期管理：组合对象需要手动close()或shutdown()，而继承下常默认由GC接管
- 过度解耦：每个小操作都拆成独立类，反而增加调用栈深度和理解成本
真正难的不是选组合还是继承，而是判断哪里该划清边界、哪些状态该封装进独立对象。这没法靠语法解决，得靠对业务稳定性的预判——而生产环境最缺的，恰恰是这种预判容错空间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
