Java接口定义行为契约，只声明方法签名与常量，支持多实现与解耦；命名需体现业务意图，配合OpenAPI/Protobuf等契约工程落地规范；面向接口编程，依赖注入替代new，default方法慎用于演进。
Java 通过接口定义统一标准和规范，核心是把“能做什么”明确写下来，让所有实现者照着做，调用方只认这个约定，不关心谁在干、怎么干。
用接口声明行为契约，不带实现也不存状态
接口只写方法签名，比如 void send(String content)，不写具体逻辑，也不放实例变量。这样微信通知、短信通知、邮件通知可以各自实现同一个 Notifier 接口，彼此互不影响。新增一种通知方式，只要实现这个接口就行，不用改已有代码。
- 方法默认 public abstract，不用显式写修饰符
- 字段只能是 public static final 常量，不能用来存运行时数据
- 避免在接口里塞 Optional 返回值，会模糊语义，影响调用方判断
命名和结构体现业务意图，方便协作理解
接口名不是 UserInterface 这类泛称，而是像 UserQueryService 或 OrderPaymentProcessor，一看就知道它负责什么。包路径也要带业务和版本信息，比如 com.example.order.api.v1，说明这是订单服务 v1 的对外契约。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 方法名用动词开头：selectUserById、createOrder、cancelPayment
- DTO、接口、错误码枚举统一放在 .api 或 .contract 包下，不混入实现类或配置
- 避免 getUserByIdAndStatus 这种拼凑型方法名，职责要单一
配合契约工程实践，让规范真正落地
接口只是载体，真要管住规范，得靠配套机制。比如用 OpenAPI YAML 先定义好请求参数、响应结构、错误码，再生成 Java 接口和 DTO 类，保证文档和代码一致；或者用 Protobuf 定义 gRPC 接口，天然支持多语言和向后兼容。
立即学习“Java免费学习笔记（深入）”；
- Controller 层用 @RequestMapping 显式声明路径，网关和注册中心才能自动识别服务
- 加 @Api(tags = "User") 和 x-service-id 扩展字段，让协作方快速定位归属服务
- 版本控制建议走路径方式（如 /api/v1/users），调试直观、路由清晰
面向接口编程，解耦调用与实现
业务代码里别写 new XXXImpl()，而是依赖接口类型，比如 List
- 集合、参数、返回值都用接口类型，不是实现类
- 一个类可实现多个接口，弥补单继承限制，灵活组合能力
- default 方法可用于接口演进，但不能访问实现细节；需要共享状态或逻辑，该用抽象类就用抽象类
