按调用方角色拆分接口，每个接口服务一类用户、含3–5个方法；依据实际调用链（如订单模块只调createorder/cancelorder、报表模块只调exportascsv/getsummary）识别零交集组合，抽为userauthenticator、useradminservice等业务语义接口，实现类仅保留真实契约，旧接口渐进式迁移。
直接按使用方角色切，不按功能动词分。一个接口只服务一类调用者，方法数控制在3–5个为宜。
看谁在用、用了哪些方法
别数接口里有多少方法，先查实际调用链：订单模块只调 createOrder() 和 cancelOrder()；报表模块只调 exportAsCsv() 和 getSummary()；两者方法零交集——这就是最硬的拆分依据。IDE 中提示 “method never used” 超过 40%，尤其集中在几个方法上，也说明这些方法对当前使用者是冗余的。
- 打开调用层级（如 IntelliJ 的 “Find Usages”），确认每个方法的真实消费者
- 统计各模块实际调用的方法集合，找出无重叠区域
- 把零交集的调用组合，各自抽成独立接口
按业务角色命名，不按 CRUD 命名
避免出现 UserCreateService、UserUpdateService 这类技术导向命名。要回归场景：前端登录模块依赖的是身份认证能力 → 提取为 UserAuthenticator；运营后台做人工审核与导出 → 定义为 UserAdminService；营销系统专注邀请码生命周期 → 建 InviteCodeManager。每个接口名一眼可知“谁用、干什么”，Java 客户端注入时也更直观。
- UserAuthenticator：含 login()、validateToken()、refreshToken()
- UserAdminService：含 freezeUser()、exportUsers()、reviewProfile()
- InviteCodeManager：含 generate()、verify()、revoke()
实现类不再写空方法或抛异常
拆分后，Robot 类只需实现 Workable（含 work()、pause()），不用管 eat() 或 fly()；短信平台只实现 SmsSender（sendSmsCode()、resendIfExpired()），完全不感知用户管理逻辑。原来满屏的 throw new UnsupportedOperationException() 或 return Collections.emptyList(); 全部消失，代码职责清晰，单元测试也只需覆盖真实行为。
- 检查所有实现类，删除未被任何调用方使用的接口方法实现
- 确保每个实现类只实现它真正参与的业务契约
- 旧接口可暂时保留为 @Deprecated，但不再新增方法
老接口迁移走三步渐进式
不强求一步到位。先让新模块用微接口；再将老模块中已明确分离的调用路径逐步切过去；最后统一替换门面层代理。例如原 UserService 接口可加一层适配器，把 UserAuthenticator + UserAdminService 组合注入，对外仍提供兼容入口，内部已解耦。
- 第一步：新增微接口，新功能全部对接微接口
- 第二步：在老服务中引入组合字段（如 private final UserAuthenticator auth;），逐步替换内部调用
- 第三步：确认无残留调用后，归档原接口，移除适配逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
