record 类在 java 14+ 中天然适合作为微服务间 dto，具备不可变性、自动生成方法、语义清晰等优势；应作为数据契约共享，配合 jackson 零配置序列化，并按场景拆分小而专的 record，不承载业务逻辑。
Record 类在 Java 14+ 中天然适合做 DTO，尤其在微服务间传递数据时——它不可变、简洁、自动生成 equals/hashCode/toString，且语义清晰，避免了传统 POJO 的模板代码和误修改风险。
用 Record 定义跨服务的数据契约
将 Record 视为“接口协议的一部分”，而非内部模型。例如订单查询返回结果：
public record OrderSummaryDTO(
String orderId,
String status,
BigDecimal amount,
LocalDateTime createdAt
) {}
服务 A 提供该 Record，服务 B 直接依赖其 jar（或共享 module），双方对字段名、类型、顺序达成强约定。比 JSON Schema 或 OpenAPI 自动生成的类更轻、更可控。
配合 Jackson 实现零配置序列化/反序列化
Record 默认支持 Jackson 2.12+（无需 @JsonCreator 或 @JsonProperty）：
- 序列化自动按字段名转 JSON 键；
- 反序列化默认按构造参数名匹配（要求 JSON 字段名与参数名一致）；
- 若需兼容旧字段名，可用
@JsonProperty("order_id")注解在参数上； - 避免使用
@JsonUnwrapped或复杂注解——保持 DTO 单一职责。
组合与分层：避免大而全的 Record
微服务通信讲求“只传所需”。不要定义一个 FullOrderDTO 包含所有字段，而是按场景拆分：
-
OrderHeaderDTO（用于列表页） -
OrderDetailDTO（用于详情页） -
OrderCreationRequest（用于创建入口，可能含校验约束注解）
必要时可嵌套其他 Record，如：public record OrderDetailDTO(
OrderHeaderDTO header,
List<orderitemdto> items,
AddressDTO shippingAddress
) {}</orderitemdto>
注意边界：不替代领域模型，也不承载逻辑
Record 是纯数据载体，不加业务方法、不继承、不实现接口（除非是标记接口如 Serializable）。不要在 Record 里写 isExpired() 或 calculateTotal() ——这些应放在服务层或专用 Value Object 中。若需校验，用 @Valid 配合 Jakarta Bean Validation 注解（Record 支持字段级注解）。
