Java接口实现契约式编程，核心是明确“能做什么”的可协作、可验证、可演进约定；通过方法签名、JavaDoc约束参数与返回值语义、default方法标注实现规范、接口组合表达角色、类注释定义协作规则与兼容承诺。
Java 接口实现行为的契约式编程，核心在于把“能做什么”明确写成可协作、可验证、可演进的约定，而不是只关注语法是否通过编译。它不是让代码跑起来，而是让不同模块、不同人、不同时期的代码能彼此信任、安全替换、清晰交接。
用接口方法签名定义前置与后置语义
每个抽象方法都是一个微型契约，JavaDoc 必须说明业务前提和结果含义：
- @param 要写约束，比如 `@param orderId 订单ID，必须为16位数字字符串，不能为空或全零`
- @return 要写业务意义，比如 `@return 支付成功返回流水号；若余额不足，返回null并触发异步补款通知`
- @throws 只列调用方必须处理的异常，如 `@throws InvalidOrderStateException 当订单状态非“待支付”时抛出，调用方应跳转至订单详情页提示用户`
用 default 方法提供可选的通用实现，但划清扩展边界
default 方法是契约的“向后兼容补丁”，不是实现指导：
- 在 JavaDoc 开头加 `@implSpec 基于本地 ConcurrentHashMap 缓存，有效期5分钟；集群部署时必须重写`
- 避免写 `推荐使用此实现` 这类主观表述，接口不评价好坏，只保障行为一致
- 多个 default 方法可互相调用，但不能访问实现类的私有字段或 this 引用
用接口组合与继承表达复合角色，拒绝胖接口
一个业务角色 = 多种能力的交集，不是所有方法堆在一个接口里：
立即学习“Java免费学习笔记（深入）”；
- 正确做法：`interface RefundOperator extends PaymentReverser, AuditLogWriter, NotificationSender`
- 错误做法：把打印小票、生成PDF、发邮件、调第三方退款API全塞进 `RefundService` 接口
- 当某方法对多数实现无意义（如 `printToPaper()` 对纯API服务），就拆出新接口，让需要的类选择性实现
用接口级 JavaDoc 定义协作规则与兼容承诺
整个接口的类注释，是给协作者看的“服务说明书”：
- 首句定义角色：`任何实现本接口的组件，都必须支持幂等退款，并在失败时保证资金状态可回查`
- 注明兼容底线：`@since v2.1.0 新增 refundWithReason(String) 方法，默认抛 UnsupportedOperationException；现有实现无需修改`
- 链接跨系统约定：`@see com.example.payment.RefundCallbackContract 回调字段命名与HTTP状态码必须与此文档一致`
