java接口的核心作用是约定契约而非定义行为，它使调用方依赖抽象类型实现松耦合与可扩展，强制实现类提供统一签名但不约束实现细节。
接口不是为了“定义行为”，而是为了约定契约
Java 接口的核心作用，是让不同类之间能通过统一的签名互相协作，而不是单纯“把方法抽出来放一起”。它强制实现类提供特定方法，但不关心怎么实现——这点常被误读为“接口=抽象方法集合”，其实更关键的是调用方依赖接口而非具体类。
比如你写一个 PaymentService 接口，下游系统只认这个接口类型，不管背后是 AlipayImpl 还是 WechatPayImpl。一旦你直接传 AlipayImpl 实例，就锁死了扩展性。
- 接口里所有方法默认是
public abstract，不能写private或protected方法（Java 9+ 支持private默认方法，但极少用） - 字段只能是
public static final，也就是常量；别试图在接口里定义可变状态 - 从 Java 8 开始支持
default方法，但仅限于向后兼容；业务逻辑仍应放在实现类中
定义接口时最容易错的三件事
很多人一上来就写 interface IService { void doSomething(); }，看似没问题，实际埋了坑。
- 没加
package声明：默认包下定义的接口无法被其他模块引用，尤其在 Maven 多模块项目中直接报cannot resolve symbol - 接口名用了动词或缩写：比如
IPayment或PayService，前者违反命名习惯（Java 不强制 I 前缀），后者模糊了“契约”本质；推荐PaymentService（名词+职责） - 把不该放进去的东西塞进接口：比如日志字段
LOG、工具方法toJson()——这些属于实现细节，放进接口等于污染契约
interface 和 abstract class 到底怎么选
不是“能用接口就用接口”，要看是否满足“纯能力声明”这个前提。
立即学习“Java免费学习笔记（深入）”；
- 如果多个类需要共享代码逻辑（比如通用校验、模板方法），用
abstract class；接口无法提供可复用的非静态字段或构造逻辑 - 如果要被多个不相关的类实现（比如
Dog和Robot都能move()），必须用interface；Java 不支持多继承，但支持多实现 - 如果未来可能添加新方法，且已有大量实现类：优先用
default方法（Java 8+），但要注意 Android API level 24 以下不支持；否则得加新接口，比如PaymentServiceV2
Spring 中 @Service 类实现接口的常见陷阱
Spring 的自动注入默认按类型匹配，而接口才是真正的“类型”。很多问题其实源于没理解这一点。
- 写了接口但没让
@Service类实现它：Spring 能启动，但@Autowired PaymentService会报No qualifying bean of type 'PaymentService' - 一个接口有多个实现类，又没加
@Qualifier：Spring 不知道该注入哪个，直接启动失败 - 接口方法抛了检查异常（
throws IOException），但实现类没声明：编译过，运行时报IllegalStateException，因为 Spring AOP 代理会拦截异常处理逻辑
接口本身没有生命周期、不参与 DI 容器管理，它只是 Spring 找 Bean 的“名字标签”。真正被管理的是实现类。
