Java接口与类本质不同：接口是行为契约，只声明“能做什么”，无状态无实现；类是实体蓝图，定义“有什么”和“怎么做”，可实例化。
Java接口和类本质不同：类是具体实现的模板，接口是行为契约的声明。 它们不是“同类事物的两种写法”，而是面向对象中承担不同职责的两种机制——一个管“怎么做”，一个管“能做什么”。
接口是行为规范，类是实体蓝图
类描述一个对象“有什么”和“怎么做”：可以有字段、构造方法、普通方法、静态块，也能被直接实例化。比如 Person 类有 name 属性、sayHello() 方法，还能 new 出具体的人。
接口只规定“能做什么”：不存状态（没有实例变量），不提供逻辑（方法默认 abstract），不能 new。它像一份合同，只写明“必须提供 run() 和 stop()”，谁签了就得照做。
常见例子：
立即学习“Java免费学习笔记（深入）”；
- Runnable 接口不关心你是线程、定时任务还是后台服务，只要实现它，就承诺可被启动执行
- List 接口不指定底层是数组还是链表，只统一定义 add()、get() 等操作行为
语法与能力差异很明确
这些区别不是细节，而是设计意图的直接体现：
- 类支持单继承（extends 只能跟一个），但可实现多个接口（implements A, B, C）
- 接口中变量自动是 public static final，方法自动是 public abstract（Java 8+ 可加 default 和 static 方法，但仍是例外，非主流）
- 抽象类可以有构造器、普通方法、protected 成员；接口完全不行
- 类可以有 private 方法和字段；接口所有成员对外完全公开，无封装粒度
设计原则：面向接口编程，不是面向实现编程
这不是口号，是解耦的关键实践。比如你写一个支付模块，不依赖 AlipayService 或 WechatPayService 具体类，而是依赖一个 PaymentProcessor 接口：
- 新增 PayPal 支持？只需写个新实现类，不用改原有调用逻辑
- 测试时可用 MockPaymentProcessor 替换真实服务，隔离外部依赖
- 业务代码只关注“发起支付”这件事，不关心背后是扫码、跳转还是 token 调用
这种松耦合让系统更易维护、可扩展、可测试。
什么时候该用接口，什么时候用类
看你要表达的是“角色”还是“实体”：
- 用接口：当多个不相关的类需要共享同一组能力，比如 Flyable（鸟、飞机、无人机都可飞，但显然不是同类）
- 用抽象类：当有一组紧密相关的子类，共享基础逻辑和状态，比如 Animal 抽象类提供 breathe() 公共实现，再由 Cat、Dog 各自实现 makeSound()
- 优先接口：API 设计、框架扩展点、策略模式、回调约定等场景，接口更轻量、更灵活
基本上就这些。
