接口是行为契约而非实现模板，核心在于定义多方共同遵守的公开行为，强调解耦与多实现；抽象类因单继承限制和状态耦合，无法替代接口在灵活性、演进性与角色建模上的优势。
接口是契约，不是模板
Java接口的核心作用是定义一组公开的、可被多方实现的行为契约。它不提供具体实现，也不管理状态，只声明“谁可以做什么”。这和抽象类有本质区别——抽象类可以含字段、构造器、部分实现；而接口只能有 public static final 字段和 public abstract 方法（Java 8+ 允许 default 和 static 方法，但仍是为契约服务的辅助手段）。
常见误解是把接口当“功能模板”去继承复用，结果写出一堆空方法或过度设计的层级。真正该问的是：这个行为是否会被多个不相关的类共同需要？是否需要解耦调用方与实现方？比如 Comparable 接口让 String、Integer、自定义 User 都能被 Collections.sort() 统一处理，调用方完全不依赖具体类型。
为什么不能用抽象类替代多数接口场景
因为 Java 不支持多继承，但允许一个类实现多个接口。如果用抽象类模拟接口行为，会立刻卡死在继承链上：
- 一个类想同时具备“可序列化”“可缓存”“可审计”能力，抽象类无法叠加，接口可以
implements Serializable, Cacheable, Auditable - 第三方库对象（如
java.time.LocalDateTime）你无法修改其父类，但可通过接口包装适配：定义TimeProvider接口，自己写个SystemClock实现，测试时换FixedClock - 抽象类带状态（如
protected int retryCount）会污染契约语义；接口强制聚焦行为，避免实现者误读“这个字段我必须用”
default 方法不是为了偷懒，而是为了演进
Java 8 引入 default 方法的真实动机，是解决接口升级时破坏二进制兼容性的问题。没有它，给已有接口加新方法会导致所有实现类编译失败。
立即学习“Java免费学习笔记（深入）”；
但滥用 default 会模糊契约边界：
- 逻辑复杂、需访问私有状态的方法不该放
default—— 这说明接口已承担实现职责，该拆出工具类或重构为策略模式 -
default方法里不要调用this.getClass().getName()做类型判断分支，这是在模拟 if-else，违背多态本意 - 优先用
default提供安全兜底（如Iterator.remove()默认抛UnsupportedOperationException），而不是塞业务逻辑
public interface Repository<T> {
T findById(String id);
// 合理：提供基础组合能力，不侵入实现细节
default List<T> findByIds(List<String> ids) {
return ids.stream()
.map(this::findById)
.filter(Objects::nonNull)
.collect(Collectors.toList());
}
}
接口命名和粒度最容易翻车的地方
接口名不是功能罗列，而是角色或能力声明。看到 UserDao 或 UserService 这类名字，大概率说明它正悄悄变成“万能胶”，后续会不断加方法、变重、难以 mock。
更稳妥的做法是按使用方视角切小接口：
-
前端 API 层需要
UserReadService（只含getById、search）和UserWriteService（只含create、update），便于权限控制和测试隔离 - 领域模型里定义
Identifiable（含getId()）、Versioned（含getVersion()），比塞进一个大接口更清晰、更易组合 - 避免动词开头（如
Validating、Logging），优先用名词体现能力（Validator、Logger），符合“它是什么”而非“它正在做什么”的建模习惯
接口一旦发布，删除方法就是破坏性变更；但新增小接口永远安全。粒度越小，后期替换、降级、打桩的成本越低。
