java接口在微服务中是服务契约，需明确调用方、参数、返回值及错误处理，统一rest与远程调用，用dto和注解确保可校验、面向业务命名，变更须向后兼容并受控。
Java 接口在微服务中定义服务契约，核心是把它当作“能力承诺书”，而不是代码容器。它不写实现，只划边界：谁可以调用、传什么、返回什么、失败怎么报。这份契约要能被机器读、被测试跑、被多人共用，不能靠口头约定或事后补文档。
用接口统一描述 REST + 远程调用契约
把接口同时作为 Spring MVC 的 Controller 契约和 Feign Client 的远程调用契约：
- 定义一个 UserApi 接口，声明
@PostMapping("/users")、createUser(@RequestBody CreateUserRequest)、返回ResponseEntity<userdto></userdto> - 服务提供方的 UserController 实现该接口，写业务逻辑
- 服务消费方的 UserFeignClient 直接继承该接口，Feign 自动完成远程调用
- 这样 URL、参数类型、返回结构、状态码含义全部由一份接口锁定，两端不会不一致
契约内容必须具体、可校验、不可模糊
避免运行时才发现问题，所有细节要在编译期和测试期就卡死：
- 参数不用
Map<string object></string>或JSONObject，每个入参都建明确 DTO 类，字段用具体类型（如LocalDateTime而非Object） - 响应体也用 DTO，不返回裸
Map或Object，确保 IDE 提示、序列化、反序列化都受控 - 错误场景要显式约定：比如 400 返回
ErrorResponse，含code和message字段，不靠字符串拼接 - 接口方法上加
@ApiResponse注解（配合 OpenAPI），标注各状态码对应响应体结构
接口设计要面向业务意图，不是技术实现
名字和结构要让团队一眼看懂“这是干啥的”，而不是“这是怎么干的”：
- 命名用动名词表达能力，如 OrderPlacement、InventoryReservation，别叫
OrderService或OrderManager - 包路径体现契约属性，统一放在
com.example.order.contract下，不混进impl或service - 接口里只放
public abstract方法（abstract可省略），不塞业务逻辑；default 方法仅用于极简通用行为（如基础字段校验），复杂流程交给实现类 - 不暴露实现细节：不出现
Impl、Stub、Proxy等后缀，也不在接口里定义数据库字段或 HTTP header 细节
契约变更必须可控、可追溯、向后兼容
接口一旦发布，就是对上下游的承诺，改它比改实现影响更大：
- 新增字段默认设为可选（DTO 中用
Optional要谨慎，更推荐设为null容忍），不破坏现有调用 - 禁止删除或修改已有方法签名（参数、返回值、异常），否则所有实现类和调用方都会编译失败
- 需要扩展行为时，优先加 default 方法，或定义新接口（如
AdvancedOrderPlacement），老接口保持不动 - 所有接口变更必须先更新 OpenAPI/YAML 文件并提交 Git，再生成代码和测试，不能先写实现再补契约
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
