Python继承全解析：单继承、多继承与super用法

Python继承远不止“子类自动获得父类方法”这么简单，真正关键的是初始化逻辑的精确传递与多继承下方法调用顺序的严谨控制：不显式调用`super().__init__()`会导致属性缺失、资源未分配、验证跳过等隐蔽运行时错误；而`super()`绝非简单的“调左边父类”，它严格遵循C3线性化生成的MRO链动态分发调用，在单继承、多继承及mixin组合中都必须统一使用`super()`而非硬编码父类名，否则极易引发逻辑断裂、重复执行或静默失效；尤其在框架开发和复杂继承体系中，参数对齐、上下文匹配（实例/类/静态方法差异）和MRO实时验证已成为避免`AttributeError`、`RecursionError`和难以调试行为缺陷的必备实践。

Python单继承里，__init__不调用父类会丢掉什么

父类的初始化逻辑直接跳过，比如属性没赋值、资源没申请、验证没执行——不是报错，而是运行时突然 AttributeError 或逻辑错乱。

常见错误现象：AttributeError: 'Child' object has no attribute 'name'，但父类明明在 __init__ 里写了 self.name = name。

• 子类 __init__ 中必须显式调用 super().__init__(...)，不能靠“自动继承”
• 参数要对齐：父类要 2 个参数，你就得传 2 个，别漏掉 **kwargs（尤其在框架代码里）
• 如果父类 __init__ 有副作用（如打开文件、注册回调），跳过它会导致后续方法完全不可用

多继承下 super() 调用顺序不是“从左到右”，而是 MRO

super() 不是简单找左边第一个父类，它按方法解析顺序（MRO）走，这个顺序可以通过 ClassName.__mro__ 查看。写死 ParentA.__init__() 看似稳妥，实则破坏协作性，尤其在 mixin 类中会出问题。

使用场景：你写了个 LoggingMixin 和 ValidatingMixin，都重写了 save()，又想让它们和 Model 一起被调用。

• 永远用 super().method()，而不是硬编码父类名加括号
• 检查 MRO：打印 Child.__mro__，确认你想调用的类确实在链上且位置合理
• 如果两个父类都定义了同名方法但没调 super()，右边那个根本不会被执行——这是最常踩的坑

super() 在静态方法、类方法、普通方法里行为不同

它不是“找上一级”，而是根据当前所在函数的类型和调用上下文，动态绑定下一个实现。误用会导致 TypeError: super(): no arguments 或静默跳过。

参数差异：

• 在实例方法里：super() 等价于 super(CurrentClass, self)
• 在类方法里：super() 等价于 super(CurrentClass, cls)，必须确保 cls 是当前类或其子类
• 在静态方法里：super() 无法推导上下文，必须显式传两个参数，否则报错

性能影响很小，但写错参数类型会让继承链断裂——比如在 @classmethod 里写成 super().some_method()（缺 cls），Python 3.10+ 会直接抛异常。

多重 mixin 组合时，super() 链断掉的典型信号

某个方法看似被调用了，但中间某层的逻辑没执行；或者同一个方法被重复调用两次——说明 MRO 没对齐，或某处用了硬编码调用绕过了 super()。

容易忽略的地方：

• 第三方库的基类（如 Django 的 models.Model）内部大量依赖 super()，你一旦在自定义类里写 Parent.save() 就可能跳过它的钩子
• 当出现 RecursionError，大概率是两个类互相调 super() 却没终止条件（比如都忘了在最终基类里去掉 super()）
• 调试时别只看类定义顺序，重点查 ClassName.__mro__ 输出，比读代码快得多

复杂点在于：MRO 是 C3 线性化算法算出来的，不是直觉能猜准的；哪怕改一个父类顺序，整个链都可能变。别靠记忆，每次不确定就 print 一下。

本篇关于《Python继承全解析：单继承、多继承与super用法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！