纯粹的规范接口是清晰、稳定、可契约化的行为约定，仅定义“能做什么”，命名用名词性业务短语如UserService，方法以标准动词开头如findById，零实现、零状态、零依赖，变更通过新增方法或版本升级保障契约稳定。
设计一个纯粹的规范接口，核心是回归接口的本质：它不是实现容器，而是**清晰、稳定、可契约化的行为约定**。不掺杂实现逻辑、不暴露技术细节、不承担多余职责，只表达“能做什么”，而非“怎么做”或“谁来做”。
接口命名与定位：聚焦业务语义
接口名必须是名词性短语，直接反映其在业务域中的角色，如 UserService、OrderRepository、PaymentNotifier。避免使用 I 前缀（如 IUserService）或 Interface 后缀，Java 语言本身已通过 interface 关键字明确类型边界。
- 不写
UserServiceInterface或UserAction这类模糊/冗余名称 - 拒绝动词命名，如
CreateUser、ValidateTokenHandler——这些属于实现类或函数式接口场景 - 若涉及多领域职责（如用户查询+权限校验+日志记录），应拆分为
UserQueryService、AuthorizationService、AuditLogger
方法定义：动词开头 + 明确语义 + 无副作用
每个方法名以标准动词起始，精准对应单一操作意图：查询用 get/find/list，新增用 create/add，修改用 update/modify，删除用 delete/remove。方法签名只暴露必要参数，返回值类型明确（不返回 void 除非确实无业务结果需反馈）。
- 不写
dealWithUser(Long id)或process(User u)这类含糊动词 - 不把多个操作合并进一个方法，例如
saveAndNotify(User user)—— 违反单一职责，也阻碍组合与测试 - 不声明异常类型（如
throws SQLException），避免将实现层技术异常泄露到契约层；统一用运行时异常或自定义业务异常封装
内容纯净性：零实现、零状态、零依赖
一个纯粹的规范接口体内只能包含：抽象方法声明、静态常量（public static final）、默认方法（仅用于非破坏性扩展，如通用工具逻辑）、静态私有辅助方法（Java 9+）。严禁出现：
立即学习“Java免费学习笔记（深入）”；
- 实例字段（
private String cacheKey;） - 构造方法或初始化块
- 对 Spring Bean、数据库连接、配置对象等任何具体依赖的引用
- 日志、监控、事务注解（如
@Transactional）——这些属于实现类关注点
契约稳定性：面向演进而非重构
一旦发布，接口即为协作契约。新增能力应通过添加新方法（或新接口）实现，禁止修改已有方法签名（参数、返回值、抛出异常）或删除方法。可借助默认方法提供向后兼容的轻量级增强：
- 旧接口
UserService已有User findById(Long id) - 需支持按邮箱查询时，增加
default User findByEmail(String email)，而非改动原方法 - 重大变更（如资源模型升级）应升级接口版本（如
UserV2Service），而非覆盖原契约
