继承链超4层易致super()失效，因MRO偏离预期；应查__mro__、显式调用super().__init__()、慎用多重手动调用；类型判断需hasattr兜底；__init__参数宜用**kwargs收口或工厂方法；静态检查需补类型注解。
继承链超过 4 层就该警惕 super() 调用失效
Python 的 super() 不是简单向上找父类，而是按 MRO（方法解析顺序）走；继承层级一深，MRO 就容易偏离直觉，导致某个 __init__ 或方法被跳过。常见现象是子类初始化后，某个中间层的字段没被赋值，但又没报错——查日志、打 print 都对不上。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
ClassName.__mro__立刻看当前类的继承顺序，别猜 - 所有重写
__init__的类，必须显式调用super().__init__()，哪怕你“觉得”父类没做啥 - 避免在中间层类里用
super().__init__()后再手动调用某个特定父类的__init__，这会破坏 MRO 链 - 如果某层只是加字段、不改逻辑，考虑用
@dataclass或普通组合替代继承
用 isinstance(obj, BaseClass) 判断时，多层继承下类型检查变脆弱
当 BaseClass 是第 5 层祖先，而实际对象是第 7 层子类实例时，isinstance 仍返回 True——这本身没错，但问题在于：业务代码可能隐含假设“只要属于 BaseClass，就一定有某个接口方法”，结果运行时报 AttributeError。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 不要只靠继承关系推断能力，用
hasattr(obj, 'method_name')或getattr(obj, 'method_name', None) is not None做兜底检查 - 如果必须强依赖接口，定义
ABC抽象基类并用@abstractmethod显式声明契约，比纯继承更可靠 - 在关键路径上，加一句
assert hasattr(obj, 'required_method')，比后期 debug 快得多
__init__ 参数爆炸：每加一层继承，构造函数就得适配上层签名
从 A → B → C → D，每层都往 __init__ 里塞新参数，最后 D 的构造函数可能带 8 个参数，其中 5 个只传给 A，中间两层根本不关心。改一个参数名或默认值，就得顺手改三四层。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
**kwargs收口，逐层消费自己需要的参数，把剩下的传给super().__init__(**kwargs) - 在最顶层基类里定义一个标准参数字典结构（比如叫
_required_init_fields），子类初始化前先校验，别等运行到一半才缺字段 - 考虑把构造逻辑拆成工厂函数或
@classmethod，比如from_config()，绕过层层传参
PyCharm / mypy 对深层继承的类型推导经常不准
静态检查工具看到 class E(D): ...，但 D 本身继承自 C(B(A))，mypy 可能无法正确追踪 A 中定义的属性是否在 E 实例上可访问，报 "E" has no attribute "x"，而运行时完全正常；或者反过来，漏掉真正缺失的属性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在中间层类加
# type: ignore要谨慎，优先补__annotations__或typing.overload - 对关键属性，在最底层子类中显式标注类型，比如
x: int，哪怕它来自祖先类 - 如果项目已用 mypy，把
--disallow-incomplete-defs和--warn-return-any加进配置，比单纯依赖继承推导更稳
深层继承最难缠的不是语法错误，而是“看起来能跑，但改一处、崩三处”的隐性耦合。一旦发现子类要频繁 patch 祖先行为，或者文档里开始出现“注意：修改本类会影响 X 和 Y 的初始化顺序”，基本就是重构信号了。
