接口核心价值在于解耦、替换与测试，通过契约约束实现统一行为，支持多继承能力组合，并借default/static方法增强实用性，但演化时仍需谨慎评估兼容性。
接口不是为了“看起来高级”，而是为了解耦、替换和测试留出空间。
接口让实现类可以随时被替换
当一个方法参数类型是 List 而不是 ArrayList，你就能在不改调用代码的前提下，把 new ArrayList() 换成 new LinkedList() 或自定义的 MyFastList()（只要它实现了 List）。这种替换能力在真实项目里非常关键：
- 数据库连接池从
HikariCP切到Druid，靠的是统一的DataSource接口 - 日志框架从
Log4j迁移到SLF4J，靠的是Logger接口抽象 - 单元测试中用
Mockito.mock(List.class)替代真实集合，依赖的正是接口的可模拟性
接口强制定义契约，避免“隐式约定”
没有接口时，不同开发者可能各自写一个 sendEmail() 方法，但参数名、返回值、异常处理各不相同。一旦用 EmailService 接口约束：
- 所有实现必须提供
void send(String to, String subject, String body) - 不能漏掉空值校验逻辑——因为接口虽不写实现，但文档和团队规范会绑定到这个签名上
- IDE 能自动提示未实现的方法，编译期就暴露问题，而不是运行时抛
NoSuchMethodError
这比靠注释或口头约定靠谱得多。
立即学习“Java免费学习笔记（深入）”；
接口支持多继承，类只能单继承
Java 类只能 extends 一个父类，但可以 implements 多个接口。比如一个业务对象既要可序列化、又要可比较、还要能转 JSON：
public class Order implements Serializable, Comparable<Order>, JsonSerializable { ... }
如果这些能力全靠抽象类提供，就得强行设计出“可序列化+可比较”的抽象基类，很快就会陷入继承树臃肿、语义混乱的境地。接口天然适合表达“能力组合”。
默认方法和静态方法让接口不再只是“空壳”
Java 8 后接口可以有 default 方法（如 Collection.removeIf()）和 static 方法（如 Comparator.comparing()），这意味着：
- 新增方法不会破坏已有实现类（只要提供默认实现）
- 工具方法可以就近定义在接口里，不用另建
XXXUtils工具类 - 但要注意：
default方法不能访问实现类的私有字段，它仍是契约的一部分，不是替代抽象类的手段
真正容易被忽略的是：接口的演化成本依然存在。哪怕加了 default，如果某个实现类已重写了同名方法，新 default 就不会生效；而如果旧实现类没覆盖，又可能因新 default 的行为改变导致逻辑错乱。
