类定义“它是什么”，接口定义“它能做什么”：类封装状态、行为和构造逻辑，接口仅声明无状态的行为契约；类支持单继承，接口支持多实现，二者在类型系统中分工明确。
类和接口根本不是同一类东西：一个是“实体蓝图”，一个是“能力契约”
类定义“它是什么”，接口定义“它能做什么”。这不是语义游戏，而是Java类型系统最底层的分工：class 负责封装状态（字段）+ 行为（方法实现）+ 构造逻辑；interface 只负责声明行为契约（方法签名），不许有实例状态，也不该承担构造职责。
常见错误现象：new MyInterface() 编译报错 Cannot instantiate the type MyInterface —— 这不是限制，是设计必然。接口没有构造器、没有实例字段，连“实例化”的语义都不成立。
- 类可以被
new，能持有private String name这样的可变状态 - 接口不能被
new，所有字段自动是public static final，比如int MAX_RETRY = 3，本质是常量池入口，不是对象属性 - 一个
Dog是Animal（IS-A），但它“能吠叫”“能奔跑”“能追踪气味”——这些能力用Barkable、Runnable、Sniffable接口表达，和“是不是动物”完全正交
什么时候必须用接口，而不是抽象类？看继承关系是否成立
关键判断标准就一条：子类和父类在业务概念上是不是同一类事物？
如果是，用抽象类（如 abstract class Vehicle → Car、Truck）；如果不是，或多个不相关类需要共享某项能力，就必须用接口（如 Serializable、Comparable、Closeable）。
立即学习“Java免费学习笔记（深入）”；
-
InputStream和FileOutputStream完全不同类，但都需支持close()—— 用AutoCloseable接口，而非抽象父类 - 你写一个
PaymentService类，想让它“可重试”“可熔断”“可监控”，这些都不是它的本质身份，而是横切能力 —— 对应Retryable、CircuitBreakable、Monitorable接口 - 滥用抽象类替代接口的后果：后续无法再继承其他类（Java单继承），且强制所有子类背负无关的字段和模板方法
Java 8+ 默认方法没改变接口本质，只是加了“契约附带参考实现”
default 方法不是让接口变类，而是解决“向后兼容升级”这个现实问题。比如 JDK 8 给 Collection 加 stream()，若不提供默认实现，所有已存在的实现类全得改代码。
但它仍受严格约束：default 方法不能访问实例字段（因为接口没有实例字段），也不能调用 this.xxx 或 super.xxx（无 super 类）。
interface Loggable {
// OK：静态常量
String PREFIX = "[LOG]";
// OK：抽象方法（契约核心）
void log(String msg);
// OK：默认方法（工具性、无状态）
default void info(String msg) {
log(PREFIX + "INFO: " + msg);
}
// ❌ 编译错误：不能声明实例字段
// private String lastMsg;
// ❌ 编译错误：不能调用 this.log()（this 在接口中无意义）
// default void warn(String msg) { this.log("WARN: " + msg); }
}
多实现 vs 单继承：这是接口不可替代的硬优势
一个类只能 extends 一个类，但可以 implements 任意多个接口。这是解耦和组合的关键机制。
典型误用：为避免重复写 toString() 就搞个 BaseEntity 抽象类，结果业务实体既要是 User 又要当 Cacheable 还要 Exportable —— 立刻卡死。
- 正确做法：
class User implements Cacheable, Exportable, Serializable，每个接口只管自己那块契约 - 抽象类适合纵向复用（同族类共性），接口适合横向装配（跨领域能力拼装）
- 注意：接口多继承（
interface A extends B, C）只是合并契约，不带来任何实现或状态，和类的继承有本质区别
class 或 interface 前，问自己一句：“我此刻是在定义一个东西，还是在约定一种能力？” 
