清查Java工程中“滥用继承”需结合工具扫描与人工研判：用PMD/SonarQube识别高风险模式，定制规则检测方法覆盖、protected滥用、深继承链等信号，再通过结构分析验证里氏替换原则与职责单一性。
要清查Java工程中“滥用继承”这类代码坏味道，不能依赖单一工具开箱即用——它属于设计层面的隐性问题，静态扫描需结合规则定制与人工研判。核心思路是：用PMD或SonarQube识别高风险继承模式，辅以自定义规则聚焦关键信号，再通过结构分析确认是否违背里氏替换原则或职责扩散。
识别滥用继承的典型信号
滥用继承往往表现为：
• 子类大量覆盖父类方法（尤其是仅做空实现或抛异常）
• 父类含过多protected字段或方法，被子类不当访问
• 继承链超过3层，且中间类无实际复用价值
• 子类只使用父类10%以下的能力，却承担全部契约
用PMD配置针对性规则
PMD默认规则集（如`design`规则组）已包含部分相关检查，但需手动启用并微调：
- 启用
UseUtilityClass和TooManyMethods，辅助发现本该用组合替代继承的臃肿父类 - 在
pmd-ruleset.xml中添加自定义规则，检测子类重写父类方法时返回new UnsupportedOperationException()或throw new RuntimeException("not implemented") - 配置
LawOfDemeter规则，标记过度依赖父类内部结构的子类调用链
用SonarQube量化继承健康度
SonarQube不直接标注“滥用继承”，但可通过指标交叉判断：
立即学习“Java免费学习笔记（深入）”；
- 关注
Depth of Inheritance Tree (DIT)：单个类继承深度＞3且Class Complexity＞20，需人工审查 - 查看
Public API Usage报告：若父类public方法被＜3个子类调用，而protected方法被频繁重写，提示封装失当 - 启用
java:S1118（工具类不应被继承）和java:S2176（避免继承非设计为扩展的类）等内置规则
人工验证与重构建议
工具报警只是起点，最终需结合语义判断：
- 对每个高DIT类，画出继承关系图，标出各子类实际使用的父类成员
- 若子类仅需父类某一部分行为，用
extract interface+composition替代继承 - 若父类存在“模板方法”但子类总绕过钩子逻辑，说明抽象层次错误，应拆分策略接口
- 检查
final缺失的父类方法——未被声明为final却从不被重写，暗示设计意图模糊
