Java接口的核心作用是作为行为契约，明确“能做什么”而非“是什么”，实现编译期类型约束与系统解耦；它通过动词性命名、最小接口粒度、依赖注入和禁止new实现类等方式，强制声明协作边界。
Java 中接口作为类型限制，核心作用是把“能做什么”明确写进代码契约里，而不是靠文档或约定去提醒别人该传什么、该返回什么。它不是语法糖，而是设计层面对协作边界的硬性声明——谁调用、谁实现、谁负责，一目了然。
用接口声明能力，而非身份
组件之间不该依赖“它是什么类”，而应依赖“它能提供什么行为”。比如一个订单服务不需要知道支付模块是 AlipayService 还是 WechatPayService，只需要它实现了 PaymentProcessor 接口：
- 接口名用动词性名词（Processor、Validator、Exporter），突出能力而非实体
- 方法签名只暴露必要参数和返回值，不泄露内部状态或实现细节
- 避免在接口中定义与当前职责无关的方法，例如 OrderService 不该包含用户通知逻辑
通过构造器或方法参数强制类型约束
组件在组装时，必须显式接收接口类型，而不是具体实现类。Spring 的依赖注入天然支持这一点：
- 服务类的构造器参数声明为 NotificationSender，而非 SmsNotificationSender
- 工厂方法或构建器返回类型也应是接口，如 createReportGenerator() 返回 ReportGenerator
- 禁止在方法体内 new 具体实现类，否则协作边界就从编译期退回到运行期
接口粒度要匹配协作场景
太粗会绑架调用方承担不需要的能力；太细又导致大量空实现或组合成本上升。判断标准是：一次协作是否只涉及一组紧密关联的行为？
- 高频共用操作（如 save()、findById()）可归入 CrudRepository
- 业务专属动作（如 reserveInventory()、cancelReservation()）应单独抽成 InventoryManager
- 跨域能力（如日志、审计、重试）建议用函数式接口（Consumer
）或策略接口，避免污染主契约
默认方法仅用于向后兼容，不替代实现类职责
Java 8+ 的 default 方法常被误用为“偷懒写逻辑的地方”，但它真正的定位是：当已有大量实现类存在时，为新增通用行为提供无破坏升级路径。
- 默认方法内不能访问实现类私有字段，也不能替代模板方法模式中的钩子逻辑
- 涉及事务、缓存、权限等横切关注点，仍应由具体实现类或 AOP 处理
- 若多个实现类共享同一段逻辑，优先考虑提取工具类或抽象基类，而非塞进接口
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
