接口设计应遵循单一职责原则，即每个接口只表达一种能力、响应一类变化，按行为维度而非实体拆分，方法粒度要单一，通过组合小接口实现复合能力，接口命名须精准反映其职责边界。
接口设计中落实单一职责原则，核心是让每个接口只表达一种能力、只响应一类变化。不是“功能越少越好”，而是“职责边界要清晰”——当某类需求变动时，只影响一个接口及其实现，不波及其他。
接口拆分：按行为维度切分，而非按实体切分
常见误区是把“用户相关操作”全塞进 UserInterface，比如包含注册、登录、密码重置、头像上传、权限校验……这些行为背后的变化动因完全不同：安全策略变（如加短信验证）会影响登录和重置，但不影响头像上传；文件存储服务切换只影响头像上传，和权限逻辑无关。
正确做法是按变化原因归类：
- AuthenticationService：只管登录、登出、令牌刷新
- PasswordPolicyService：只管密码修改、强度校验、历史密码检查
- ProfileMediaService：只管头像/封面图的上传、裁剪、URL生成
- PermissionChecker：只管角色判断、资源访问授权
方法粒度：一个方法只做一件事，拒绝类型参数或状态分支
避免用枚举或字符串控制行为的“万能方法”，例如：
❌ 不推荐void updateUser(UpdateType type, Object data) —— 调用方传错 type 就静默失败，接口契约模糊，无法单独测试或 mock。
拆成明确命名的方法：
updateUsername(String userId, String newUsername)updateEmail(String userId, String newEmail)changePassword(String userId, String oldPwd, String newPwd)
每个方法意图一目了然，变更影响范围可控，也便于后续添加校验、日志、监控等横切逻辑。
组合优于继承：用接口组合表达复合能力
不要为“全能角色”定义大而全的接口（如 AdminUserService），而应让实现类组合多个小接口：
public class UserAdminService implements UserService, PasswordPolicyService, PermissionChecker
这样前端或调用方可根据实际需要依赖具体接口，而不是被迫引入一整套不相关的契约。测试时也能精准 mock 某一能力，不被无关逻辑干扰。
警惕隐式职责：接口名要真实反映能力边界
接口名本身是契约的第一道防线。以下命名都含隐患：
-
UserManager—— “管理”太宽泛，不清楚管什么 -
UserHelper—— 辅助类容易不断堆砌方法，变成垃圾桶 -
UserAPI—— 暗示 HTTP 层，但接口应关注能力，不绑定协议
更合适的命名示例：
-
UserQuery（只查，不改） -
UserRegistration（仅注册流程，含验证码、邮箱校验等） -
UserDeletionPolicy（专注软删、数据脱敏、关联清理策略）
名字即责任，名字变了，往往意味着职责已迁移或拆分。
