继承深度本身不直接决定性能优劣，但会放大底层机制开销并抬高理解、修改与验证成本；真正影响程序质量的是变量共享方式、方法查找机制和生命周期管理。
继承深度本身不直接决定性能优劣，但会放大底层机制的开销，并显著抬高理解、修改与验证成本。真正影响程序质量的，不是“有多少层”，而是“变量如何共享”“方法如何查找”“生命周期如何管理”。
系统变量跨层级污染风险
深层继承常把类变量（如 Java 的 static、Python 的 cls.xxx）暴露在长链顶端，导致多个子类无意间共用同一份状态。
- Java 中顶层基类定义 static Map<String, Object> cache，不同业务子类写入时 Key 冲突或并发未加锁，引发数据错乱
- Python 父类设 cls.config = {}，子类 A 调用 update() 后，子类 B 读到已被篡改的内容
- C++ 基类声明 protected static int sequence_id，各派生类自增时无同步，造成 ID 重复或跳变
方法调用与类型推断变得不可靠
继承越深，IDE 跳转越容易停在父类声明而非真实实现；运行时实际执行哪个版本的方法，越来越难静态判断。
- Ctrl+Click 只跳到抽象方法或接口，无法直达子类重写体
- 调用栈中频繁出现 $$EnhancerBySpringCGLIB 或 Proxy$，说明 AOP/代理已介入，原始继承结构失效
- JVM 的 JIT 编译器可能因类型不稳定拒绝优化热点方法，表现为 -XX:+PrintCompilation 中长期显示 “made not entrant”
调试与测试覆盖严重失真
一个变量异常或一行逻辑出错，需要逆向排查从当前类→所有父类构造器→初始化逻辑→更上层父类，路径呈指数级增长。
- 在关键入口加 System.out.println(getClass())，比画 UML 图更快确认真实类型
- 覆盖率报告里显示“子类方法已覆盖”，但实际只走通了父类空实现，属于假覆盖
- 修改祖父类某个字段默认值，CI 中大量非直系子类测试失败，说明隐式依赖已失控蔓延
内存与生命周期管理易错配
不同层级对同一字段的持有意图不一致：父类当全局单例，子类却反复新建；父类设计为弱引用，子类注册强回调阻断 GC。
- 顶层基类持 self._pool（数据库连接池），中间子类析构时调用 close()，导致其余子类后续操作全部失败
- 配置类继承链中，上层加载 YAML 为不可变字典，下层用 dict.update() 就地修改，破坏一致性保障
- self._event_handlers 设为弱引用列表，某子类注册强引用回调，使整棵树对象无法被回收
