应拆解“大而全”契约，仅保留实际调用方法；通过调用链扫描识别真实使用接口；用适配器封装并暴露最小专用接口；按业务场景拆分契约，如orderpayment、refundservice等；将变更影响限定在单个适配器内，提升系统可控性与健壮性。
直接拆掉“大而全”的契约，只保留当前业务真正调用的方法。这不是删代码，而是把原本强加给你的依赖关系，换成你主动选择的最小契约。
识别第三方组件中实际被调用的接口方法
很多团队拿到第三方 SDK 或业务组件后，直接 implements 它提供的总接口，哪怕只用其中 20% 的能力。先做一次真实调用链扫描：查看日志、埋点、或用 IDE 的“Find Usages”，确认项目里真正调用过哪些方法。比如某支付组件声明了 15 个方法，但你只用了 init()、pay() 和 queryOrder()，其余 12 个就是冗余契约。
用适配器封装原始接口，暴露专用小接口
不要修改第三方代码，而是新建一个轻量级适配器：
- 定义一个仅含 3 个方法的 PaymentService 接口（init/pay/queryOrder）
- 写一个 AlipayAdapter 类，内部持有原始 SDK 实例，只把那 3 个方法桥接到 SDK 对应实现
- 业务层只依赖 PaymentService，完全不知道 AlipaySDK 的存在
这样，SDK 升级时若新增或删除无关方法，你的系统不会编译失败，也不会因未实现新方法而报错。
按业务场景拆分契约，避免“一接口通吃”
同一个第三方组件，在下单、退款、对账等不同场景下，所需能力完全不同。与其让所有模块都依赖一个臃肿接口，不如按职责切分：
- OrderPayment 接口：只含 pay() 和 cancel()
- RefundService 接口：只含 refund() 和 queryRefund()
- ReconciliationReader 接口：只含 fetchDailyReport() 和 verifyRecord()
每个接口对应一个明确的业务动作，实现类也自然聚焦——退款逻辑不会意外触发对账行为，降低了误用和耦合风险。
把变更影响范围控制在单个适配器内
第三方组件升级时，常伴随接口废弃、签名变更或行为调整。如果所有业务都直连原始接口，一次升级可能波及十几个服务。而采用隔离后的结构：
- 只有 AlipayAdapter 需要修改，其他业务代码完全不动
- 适配器内部可做兼容处理（如旧版 queryOrder 返回 Map，新版返回 OrderVO，适配器统一转成你定义的 OrderDTO）
- 甚至可并行支持多版本 SDK，通过策略模式切换，实现灰度迁移
系统健壮性不来自“不改”，而来自“改得可控”。接口隔离让每次外部变动，都变成一次局部重构，而不是全局救火。
