java接口演进史是功能扩展与向后兼容持续权衡的实践史：jdk8引入default方法实现“加功能不改实现”，jdk8/9分别增加静态与私有方法完善逻辑组织能力，多实现冲突由编译期强制解决，vector与arraylist对照体现“不删只引导”的渐进兼容逻辑。
Java 接口的演进历史，本质上是一部在功能扩展与向后兼容之间持续权衡的实践史。它不靠激进重构，而是用渐进式设计守住“老代码还能跑”这条底线——这对任何需要长期维护的系统都极具参考价值。
默认方法：让接口“加功能不改实现”成为可能
在 JDK 8 之前，往接口里加一个新方法，等于强制所有实现类立刻修改，否则编译失败。这在大型生态中几乎不可行——比如 List 接口新增 sort() 方法，若没有默认方法，成千上万自定义 List 实现（如 Guava 的 ImmutableList）全得重写。
- 默认方法通过 default 关键字提供可选实现，旧实现类无需改动即可继承使用；
- 它不是语法糖，而是编译器和 JVM 协同支持的机制，保证字节码层面兼容；
- 实际效果是：API 可以进化，但二进制契约（.class 文件）不变。
静态方法与私有方法：把“接口也能组织逻辑”落到实处
JDK 8 引入静态方法，JDK 9 补上私有方法，这两步看似小，实则补全了接口作为“契约+能力中心”的定位。
- 静态方法（如 Comparator.naturalOrder()）提供工具性入口，不破坏实例行为契约；
- 私有方法封装重复逻辑，避免 default 方法间代码冗余，同时不暴露给实现类——既提升可维护性，又不增加实现负担；
- 关键点在于：这些新增能力全部不改变接口的“抽象签名集合”，实现类视角下，接口还是那个接口。
多实现冲突的显式解决机制：把兼容风险收口到编译期
当一个类实现多个含同名 default 方法的接口时，Java 要求必须重写该方法。这不是限制，而是保护。
- 它把潜在的行为歧义提前暴露在编译阶段，而不是运行时随机调用某一方逻辑；
- 同时提供 InterfaceName.super.method() 语法，允许开发者按需复用任一父接口的原始实现；
- 这种“强制决策 + 精确控制”的设计，让兼容性不再依赖猜测，而依赖明确意图。
Vector 与 ArrayList 的对照：兼容性有时意味着“不删，只引导”
Vector 自 JDK 1.0 就存在，同步设计在单线程场景下成了性能包袱。但 Java 没有废弃它，而是保留其语义、引入更优替代（ArrayList），再通过文档、工具警告、社区共识逐步迁移。
- 接口演进也遵循同样逻辑：不删除旧方法，不改变已有行为，只叠加新能力；
- 真正的兼容性不是“零变化”，而是“变化可预期、可控制、可回退”；
- 用户升级 JDK，不需要重写业务代码，只需要在需要时才启用新特性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
