接口设计应按行为职责拆分为小接口，如Flyable、Swimmable；面向不同调用方提供定制化契约，如OrderQuery、OrderPayment；新增能力优先用default方法；物理层需在OpenAPI、SDK、部署层面隔离。
核心是让每个接口只表达一种明确能力，从调用方视角出发拆分，而不是堆砌方法。
按行为职责拆分成小接口
一个接口只定义紧密相关的一组操作，避免“全能但无用”的大接口。比如把动物行为混在一个接口里，会导致某些实现类被迫空实现无关方法。
- 定义 Flyable：只含
fly() - 定义 Swimmable：只含
swim() - 定义 Runnable：只含
run()
Bird 实现 Flyable 和 Runnable，Fish 只实现 Swimmable，各取所需，没有冗余负担。
面向不同调用方提供定制化契约
同一业务实体，对 App 用户、支付网关、后台运营等角色，暴露各自真正需要的接口，不搞“一接口通吃”。
立即学习“Java免费学习笔记（深入）”；
- App 用户只需 OrderQuery（含
getOrderById()） - 支付网关依赖 OrderPayment（含
pay()、cancel()） - 后台运营使用 OrderAdmin（含增删改查及导出）
这样某一方升级逻辑时，其他模块完全不受影响，也不用重新编译。
用 default 方法支持平滑演进
接口需要新增能力时，优先加 default 方法，避免直接添加抽象方法迫使所有实现类改动。
- 新增日志需求？加
default void logAction(String action) { /* 空实现或基础打点 */ } - 已有实现类无需修改即可通过编译
- 后续子类按需重写，老代码保持稳定
注意 default 方法只是演进缓冲，不能代替职责拆分本身。
物理层也要隔离，不止于代码
接口隔离要落到契约文件、SDK 和部署层面才算真正落地。
- OpenAPI 按角色拆成多个 YAML 文件，如
app-user-api.yaml、admin-user-api.yaml - 共用 DTO 抽到独立
shared-models.yaml，用$ref引入，避免字段不一致 - Dubbo 中按场景定义多个 interface，如
UserReadService和UserAdminService，不共用一个UserService
不复杂但容易忽略。
