接口隔离原则要求按调用方角色和真实使用场景定义精简接口，如LoginCapable、EmailCapable；通过调用分析确定最小契约，用适配器封装第三方接口，按业务动作拆分接口以聚焦职责、防止误用。
接口隔离原则的核心是让每个接口只暴露调用方真正需要的方法，避免“一接口通吃”带来的冗余依赖和耦合风险。设计精简接口不是单纯删方法，而是围绕真实使用场景做减法和聚焦。
按调用方角色定义接口
不要按功能模块（如“用户管理”）堆砌方法，而要看谁在用、怎么用：
- Web 控制层只需要 login() 和 logout() → 定义 LoginCapable 接口
- 通知服务只调用 sendEmail() → 单独定义 EmailCapable 接口
- 后台任务只执行 generateReport() → 提供 ReportCapable 接口
一个类可同时实现多个小接口，比强行实现一个含 10 个方法却只用 2 个的“UserOperation”更自然、更安全。
从真实调用链反推最小契约
别凭经验猜，用数据确认哪些方法真正在用：
立即学习“Java免费学习笔记（深入）”；
- 用 IDE 的 “Find Usages” 查看项目中实际调用了第三方接口的哪些方法
- 分析日志或埋点，确认生产环境中高频使用的入口
- 比如某支付 SDK 声明了 15 个方法，但你的系统只调 init()、pay()、queryOrder() → 这三个就是你当前业务的真实契约
没被调用的方法，就是潜在的变更雷区，不该出现在你的依赖边界里。
用适配器封装原始接口，暴露专用小接口
不改第三方代码，也不让业务直连大接口：
- 新建 PaymentService 接口，仅含 init()、pay()、queryOrder()
- 写 AlipayAdapter 类，内部持有原始 SDK 实例，只桥接这 3 个方法
- 所有业务代码只依赖 PaymentService，完全屏蔽 AlipaySDK 的存在
这样 SDK 升级时新增或废弃无关方法，你的编译和运行都不受影响。
按业务动作拆分，而非按组件切分
同一个第三方能力，在不同流程中职责不同，就该有不同接口：
- OrderPayment：只含 pay() 和 cancel()
- RefundService：只含 refund() 和 queryRefund()
- ReconciliationReader：只含 fetchDailyReport() 和 verifyRecord()
每个接口对应一个明确的动作意图，实现类逻辑聚焦，也天然防止误用——退款服务不会意外触发对账行为。
