接口是定义行为契约的机制，强调“能做什么”而非“是什么”，支持依赖倒置与里氏替换，应按能力粒度设计、避免滥用default方法。
接口是契约，不是模板
Java 接口的核心作用不是为了“写个空方法等着被实现”，而是定义一组public abstract方法的契约——谁实现它，就必须提供这些行为的具体语义，且调用方只依赖这个契约，不关心具体是谁、怎么实现的。
这直接支撑了面向对象中「依赖倒置」和「里氏替换」：上层模块依赖 PaymentProcessor 接口，而不是 AlipayProcessor 或 WechatProcessor 类；只要它们都实现了该接口，就能无缝替换。
- 接口中所有方法默认是
public abstract，不能有方法体（Java 8+ 允许default和static方法，但它们是辅助契约的，不是契约本身） - 接口不能被实例化，也不能包含实例字段（只有
public static final常量） - 一个类可以
implements多个接口，这是 Java 单继承限制下的关键扩展能力
什么时候该用接口而不是抽象类
判断依据不是“有没有共用代码”，而是“是否在描述一种能力（can-do）还是某种事物（is-a）”。
Runnable、Comparable、Closeable 都是能力型接口——任何类都可以具备“可运行”“可比较”“可关闭”的能力，和它本身的类型无关；而 AbstractList 是抽象类，因为它代表“一类列表”的共性结构，子类天然属于这个谱系。
立即学习“Java免费学习笔记（深入）”；
- 优先用接口表达“能做什么”（例如
Authenticator、Serializer） - 当需要共享状态或非公开逻辑时，才考虑抽象类；但若只是共享实现，更推荐组合 + 接口 + 工具类（如
Collections中大量静态方法） - Java 8 后，
default方法让接口能提供简单通用实现（比如List.sort()），但别把它当成抽象类用——一旦出现条件分支、字段访问或复杂流程，就该抽成独立实现类
interface 中的 default 方法容易踩的坑
default 方法本意是向后兼容（如 Java 8 给 Collection 加 stream()），但它会引发菱形继承问题：当一个类同时实现两个都有同签名 default 方法的接口时，编译器会报错，强制你重写该方法。
interface A {
default void log() { System.out.println("A"); }
}
interface B {
default void log() { System.out.println("B"); }
}
class C implements A, B {
// 编译错误：class C inherits unrelated defaults for log() from types A and B
// 必须显式覆盖：
public void log() { A.super.log(); } // 或 B.super.log()
}
- 不要在
default方法里访问this的非接口成员（会破坏封装，也违背接口初衷） - 避免在
default方法中抛出受检异常（throws IOException），因为实现类可能无法或不想处理它 - 如果多个接口提供了相似的
default方法（如map()在Stream和自定义接口中），务必检查签名是否完全一致（包括返回类型、泛型边界）
接口命名与粒度控制的实际影响
接口名不是随便加个 I 前缀或 able 后缀就行。名字决定使用者对能力边界的预期，粒度过粗或过细都会导致实现困难或滥用。
比如 DataService 过于宽泛，实现类可能被迫暴露不相关的增删改查；而 CanLoadById 又太窄，难以复用。更合理的是按场景拆分：UserQueryService（只查）、UserCommandService（只改），或者遵循 Repository 模式，用泛型约束操作范围：Repository<user long></user>。
- 避免动词开头（如
SendEmail），应使用名词表达角色或资源（EmailSender） - 单方法接口（SAM）适合用 Lambda 替代，如
Function<t></t>，但业务接口别刻意凑成 SAM——OrderValidator明显比ValidateOrder更符合语义 - 接口方法参数尽量用不可变类型或接口（
List<string></string>而非ArrayList<string></string>），否则会把实现细节泄露给契约
