抽象类不适用于跨服务契约，仅限单服务内封装通用逻辑；跨服务契约须通过api接口、openapi规范及dto等显式协议定义，避免继承导致的隐式耦合。
抽象类在微服务架构中不直接定义跨服务的“公共契约”，因为契约本质是服务间通信的协议，应由接口（API）而非实现类承载。但抽象类可在单个服务内部封装通用行为，为同服务下的多个业务实现提供统一骨架和约束。
抽象类适合放在服务内部，而非跨服务共享
微服务强调松耦合与独立部署。若将抽象类打包进共享库并被多个服务依赖，会导致隐式耦合：一个服务修改抽象类，可能迫使其他服务同步升级，违背微服务演进原则。
- 抽象类应仅存在于服务自己的代码模块中（如
service-core模块），供该服务内不同 Controller、Service 或 Domain 实现复用 - 跨服务契约必须通过明确、版本化的 API（如 OpenAPI 规范）和数据结构（如 DTO、Schema）表达，而非 Java 类继承关系
- 若多个服务确实需要相似逻辑，优先考虑提取为独立的、语义清晰的领域服务，或通过事件驱动解耦，而不是共享抽象类
用抽象类统一服务内的业务处理流程
例如，在订单服务中，创建不同类型订单（普通订单、预售订单、团购订单）需共用校验、幂等、日志、状态机初始化等步骤，但核心创建逻辑各异——这正是抽象模板方法模式的典型场景。
- 定义抽象基类
AbstractOrderService，声明create()为模板方法，内含公共步骤；将差异部分（如库存扣减策略、支付规则）声明为protected abstract方法 - 各子类（
NormalOrderService、PresaleOrderService）只关注自身业务逻辑，不重复编写基础设施代码 - 配合 Spring 的
@Primary或限定性@Qualifier，便于在运行时注入具体实现
避免把抽象类当“远程契约”来设计
常见误区是让消费方服务继承提供方的抽象类，试图“强制一致”。这会造成编译期强依赖，且无法应对网络延迟、超时、熔断等分布式固有特性。
- 服务间交互应基于 HTTP/gRPC 接口 + JSON/Protobuf 协议，契约以接口文档和 Schema 为准
- DTO 对象应是简单 POJO，不含逻辑、不继承任何抽象类；序列化/反序列化过程不应依赖 Java 继承体系
- 若需复用验证逻辑，可将校验规则抽成独立的
Validator工具类或使用 Bean Validation 注解，而非靠继承传递
真正需要“契约一致性”时，用 API 优先方式替代类继承
当多个服务要遵循同一业务规范（如统一的用户认证流程、审计日志格式），应通过标准化 API 设计与治理实现，而非 Java 层面的抽象类。
- 使用 OpenAPI 3.0 定义统一的请求/响应结构、错误码、Header 约定，并生成多语言客户端 SDK
- 通过 API 网关统一注入鉴权、限流、日志字段，下游服务只需按约定解析，无需继承特定基类
- 内部服务间调用可引入轻量级契约测试（如 Pact），验证实际 HTTP 行为是否符合约定，比编译期继承更可靠
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
