接口设计应聚焦能力契约而非功能堆砌，需拆分小接口明确职责、限制default方法为轻量钩子、善用private接口方法封装共用逻辑，并定期清理过时扩展点。
接口污染与膨胀，本质是把接口当成了“功能堆砌区”，而不是“能力契约”。关键不在删方法，而在厘清职责边界、控制扩展方式、尊重实现自由。
聚焦契约，拆分小接口
一个接口只承诺一类明确行为。比如订单处理，不要定义一个 OrderService 接口塞进校验、风控、积分、日志、通知等十种 default 方法。而是拆成：
-
OrderValidator：只声明
validate(Order order) -
RiskChecker：只声明
check(Order order) -
AuditFiller：只声明
fillAuditContext(Order order)
实现类按需 implements，避免为用不到的能力写空实现或被迫提供依赖（如缓存、配置）。
default 方法只做“钩子”，不带逻辑包袱
default 方法应是轻量级的可选入口，不封装业务主干，也不隐式绑定实现细节：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 禁止调用
this.getConfig()、this.getCache()等未在接口中声明的方法或字段 - 所有外部依赖（如日志器、策略对象、工具类）必须通过参数传入
- 若逻辑稍重，优先提取为静态工具方法，而非塞进接口
这样，即使某个实现类不关心该扩展点，也不会因缺少某字段或方法而编译失败或运行报错。
善用 private 接口方法封装共用逻辑
JDK 9+ 支持接口中定义 private 方法，这是组织 default 方法内部细节的正确方式：
- 把多个 default 方法里重复的判空、格式化、拼接逻辑，抽成
private String normalize(String s) - 它不会暴露给实现类，不增加契约负担，也不引发继承污染
- 相比复制粘贴或新建工具类，它更内聚、更易维护
定期审查与清理过时扩展点
default 方法一旦发布，就成为兼容性负担。要像管理 API 一样管理它们：
- 上线后半年内无任何实现类重写或调用的 default 方法，应标记
@Deprecated - 下一个大版本中移除，配合文档说明替代方案
- 用
javap -v YourImpl.class检查是否意外引入了桥接方法或合成字段
接口不是仓库，不该囤积“以防万一”的能力。宁可多建一个小接口，也不要在一个接口里堆十个 default 方法。
