接口隔离原则（ISP）要求客户端只依赖所需接口，避免臃肿接口导致冗余实现与职责混淆；应按业务角色拆分接口、用组合替代继承，并通过渐进式迁移保障兼容性。
接口隔离原则（ISP）的核心是：客户端不应依赖它不需要的接口。当一个接口定义了太多方法，而不同客户端只用其中一部分时，这个接口就“臃肿”了——强行实现所有方法会导致冗余、空实现、违背开闭原则，甚至让调用方难以理解该接口的真实职责。
识别臃肿接口的典型信号
以下情况往往意味着接口违反了ISP：
- 实现类中大量方法抛出 UnsupportedOperationException 或只写 return null; / return Collections.emptyList();
- 同一个接口既被订单服务调用，又被报表服务和通知服务实现，但三者用到的方法完全不重叠
- IDE 提示 “Method is never used” 的比例超过 40%，尤其集中在某几个方法上
- 单元测试里需要 mock 出十几个方法，但实际只验证其中 2–3 个
按业务角色拆分接口（推荐起点）
不要从技术动作（如 create/update/delete）出发，而是回到“谁在用、为什么用”的场景。例如原有一个 UserService 接口包含登录、发短信、导出Excel、审核用户、生成邀请码等12个方法：
- 前端登录模块只关心 login() 和 validateToken() → 提取为 UserAuthenticator
- 运营后台需要审核、冻结、导出 → 提取为 UserAdminService
- 营销系统要生成、校验邀请码 → 提取为 InviteCodeService
- 短信平台仅调用 sendSmsCode() → 单独定义 SmsSender（可复用到其他业务）
拆分后每个接口职责单一，命名直指用途，Java 客户端按需注入，不再被迫实现无关逻辑。
立即学习“Java免费学习笔记（深入）”；
用组合代替继承式扩展
避免为了“统一管理”把多个能力塞进一个父接口，再让子类选择性实现。比如：
❌ 反例：UserOperation extends Readable, Writable, Exportable, Notifiable —— 四个标记接口，但实际只有 20% 的 UserOperation 实现了 Notifiable
✅ 改进：- 保留核心接口 UserRepository（只含 findById、findAll 等读操作）
- 需要写的模块额外注入 UserWriter（save、delete）
- 需要导出的模块注入 UserExporter（exportToExcel、exportToCsv）
- 是否通知由调用方决定，通过事件总线或回调函数传入，不固化在接口契约中
对老接口做渐进式迁移（不破环兼容）
已有项目无法直接删改接口？用“双接口并存 + 注解引导”过渡：
- 保留旧接口，但标注 @Deprecated 并注明替代接口名
- 新功能全部使用拆分后的细粒度接口
- 在 Spring 中用 @Primary 控制默认注入目标，同时允许显式指定 @Qualifier("userAuthenticator")
- 配合 SonarQube 规则禁止新代码引用旧接口，半年内逐步清理
这样 Java 客户端可以按节奏升级，不影响上线稳定性。
