接口是契约声明而非模板，只定义行为（方法签名、常量、default/静态方法），不提供实现；解耦依赖接口而非具体类，需配合依赖注入（如构造器注入、工厂、ServiceLoader、Spring @Autowired）落地；default和private方法影响演进自由度，小而专的接口更利于组合与隔离；测试暴露设计缺陷，异常应抽象为业务语义而非技术细节。
接口不是模板，是契约声明
Java 接口本身不提供实现，只定义行为契约——方法签名、常量、默认方法和静态方法。它不关心“谁来做”，只规定“能做什么”。解耦的关键正在于此：调用方只依赖 Interface，不依赖任何 ConcreteClass。比如你写一个日志模块，定义 Logger 接口，业务代码只调用 logger.log(message)，完全不知道背后是 FileLogger 还是 SlackWebhookLogger。
依赖注入才是解耦落地的核心手段
光有接口没用，必须让运行时对象真正按接口类型被创建和传入。硬编码 new FileLogger() 会立刻破坏解耦。常见做法包括：
- 构造器注入：类的构造方法接收
Logger类型参数，由外部（如 Spring 容器或测试代码）传入具体实现 - 工厂模式：用
LoggerFactory.getLogger(type)返回符合Logger接口的实例，避免调用方感知实现类名 - ServiceLoader：在
META-INF/services/下声明实现类全限定名，运行时动态加载，适合插件化场景
Spring 的 @Autowired 本质也是基于接口类型查 Bean，前提是该接口有且仅有一个非 @Primary 的实现类，否则抛 NoUniqueBeanDefinitionException。
default 方法和 private 方法影响接口演进自由度
JDK 8+ 允许接口含 default 方法，看似方便，但容易误用成“伪抽象类”。一旦在接口中添加 default 实现，所有实现类自动继承——这会悄悄扩大契约范围，后续修改可能引发意料外的行为变更。更隐蔽的风险是：如果多个接口有同签名 default 方法，实现类必须显式重写，否则编译失败。
立即学习“Java免费学习笔记（深入）”；
Java 9+ 支持接口内 private 方法，用于复用 default 方法逻辑。但它不改变接口的契约性质，只是语法糖。真正影响解耦的是设计粒度：接口越小越专注（如 Readable、Writable），组合使用越灵活；大而全的接口（如 UserService）反而导致实现类被迫实现无关方法，违背接口隔离原则。
public interface PaymentProcessor {
void charge(BigDecimal amount);
void refund(BigDecimal amount);
// 谨慎添加 default：这里加了就等于承诺所有实现都支持“批量退款”
default void batchRefund(List amounts) {
amounts.forEach(this::refund);
}
}
测试阶段暴露接口设计缺陷最直接
写单元测试时如果发现要 mock 十几个方法才能测一个功能，说明接口太胖；如果每次换实现都要改一堆 if (logger instanceof XxxLogger) 判断，说明调用方偷偷依赖了实现细节。真实项目里，最容易被忽略的是异常契约——接口方法是否声明 throws IOException？不同实现对异常的处理策略（重试 / 降级 / 熔断）应封装在实现内部，接口不应暴露底层技术异常，而应定义业务语义异常如 PaymentRejectedException。
