架构量化指标将继承与组合选型从经验判断转向可观测治理，涵盖耦合强度（如继承链深度≤3、重写方法占比＞60%需重构）、可维护性（如组合依赖扇出数建议1–3、继承树变更扩散率＞30%触发警报）和组织协同（如PR决策注释率、架构雷达命中率、新人违规率）三类指标。

制定团队开发中关于类继承与组合模式选型的架构量化指标，核心是把设计决策从经验判断转向可观测、可对比、可演进的技术治理行为。指标不是为了打分排名，而是为了暴露耦合风险、识别重构时机、支撑技术债管理，并在评审、新人培训和代码扫描中形成一致语言。

一、耦合强度类指标（直接反映继承/组合对系统健康的影响）

这类指标聚焦“修改一个类是否容易波及其他类”，是继承滥用最典型的副作用：

• 继承链深度（Inheritance Depth）：统计每个类向上追溯至根类（如Object、BaseEntity）的继承层数。建议阈值≤3；超过4层需强制评审——深度每+1，子类对父类变更的敏感度呈指数上升。
• 重写方法占比（Override Ratio）：某类中被override的方法数 ÷ 该类继承自父类的可重写方法总数。若＞60%，说明父类抽象不正交，或子类在“打补丁”而非扩展，应优先考虑组合+策略模式替代。
• 组合对象接口稳定性得分（Composition Interface Stability）：对类所依赖的组合对象接口（如PaymentProcessor），统计其近6个月方法签名变更次数。得分=100 − （变更次数 × 25）。低于70分的接口，要求组合方增加适配层或契约测试，避免“牵一发而动全身”。

二、可维护性类指标（衡量长期演化成本）

继承易导致“改一处、崩一片”，组合则更考验接口定义质量。指标需覆盖静态结构与动态行为：

• 组合依赖扇出数（Composition Fan-out）：一个类内部声明的非基础类型（如String、int）组合对象数量。均值建议控制在1–3个；超过5个需检查是否违反单一职责，或应拆分为更小的协作单元。
• 继承树变更扩散率（Inheritance Tree Churn Rate）：过去一个迭代周期内，某继承树中任意类发生变更（含新增、删除、修改方法/字段）后，引发同树其他类同步修改的次数 ÷ 总变更次数。＞30%即触发架构警报，提示该树已成“高危区”。
• 组合替换可行性得分（Swappable Composition Score）：基于单元测试覆盖率与Mock使用情况计算。若某组合对象（如CacheService）有≥80%核心路径被测试覆盖，且所有测试均可通过注入不同实现（RedisCache / CaffeineCache）通过，则得满分100；否则按覆盖率线性扣减。目标值≥85，确保组合真正“可插拔”。

三、组织协同类指标（让架构决策落地到团队动作）

再好的指标若不嵌入流程，就只是报告里的数字。需绑定关键研发触点：

• PR中继承/组合决策注释率：要求在新增或重构涉及继承/组合的类时，必须在PR描述中填写固定模板：“选用[继承/组合]因[is-a/has-a]关系明确；对比方案为[简述替代方式]；已验证[具体验证项，如：父类无强状态依赖/组合接口已契约化]”。未填写者CI自动拦截。
• 架构雷达季度更新命中率：团队技术雷达中，“推荐组合”“慎用多层继承”等条目，需在季度代码扫描中匹配对应实践。例如：新模块中继承深度≤2的比例 ≥95%，未达标则进入下季度改进计划。
• 新人首次提交的继承违规率：统计入职30天内新人代码中违反上述指标（如继承深度＞3、重写率＞70%）的比例。若连续两期＞15%，说明设计原则未有效传达，需优化培训材料或引入结对编程Checklist。

这些指标不追求绝对精确，但能快速定位“哪里开始松动”。它们共同指向一个事实：继承是编译期绑定的强契约，组合是运行期可协商的协作协议。选型不是非此即彼，而是根据变化频率、影响范围和团队认知负荷，选择代价更低的那条路。