DTO 是专用于层间数据传输的精简无逻辑POJO，本质区别在于其明确职责：仅含必要字段且禁止业务方法；而POJO是泛称，无功能约束。
DTO 是什么，和 POJO 有啥本质区别
DTO 不是 Java 语言特性，也不是框架规范，它只是开发者约定俗成的一种“数据搬运工”角色：只负责在不同层之间（比如 Controller 和 Service）安全、轻量地传递数据。它和 POJO 的最大区别在于目的性——POJO 是泛称，指“没继承、没实现特定接口、没依赖框架的普通 Java 对象”，而 DTO 是一种有明确职责的 POJO，必须满足两个硬条件：字段精简（只传需要的）、无业务逻辑（不能有 save() 或 calculateTotal() 这类方法）。
常见错误现象：UserDTO 里塞了 password 字段，或者加了 isValidEmail() 校验方法；这已经不是 DTO，而是混入了 VO 或 Domain Logic 的“四不像”。
- 使用场景：前后端交互时，Controller 接收
UserCreateDTO，而不是直接接收UserEntity - 参数差异：DTO 字段通常比 Entity 少（比如 Entity 有
createdAt、updatedAt，DTO 不暴露） - 性能影响：DTO 越小，序列化/反序列化越快，网络传输负担越低
Entity 和 VO 到底谁该包含格式化字段
Entity 必须严格对应数据库表结构，字段名、类型、空值约束都得和 ORM 映射一致；VO（View Object）则专为前端展示服务，可以也**应该**包含格式化内容。这是分工边界，踩错就容易引发数据污染或维护混乱。
典型翻车现场：UserEntity 里写了个 getFullName() 返回 firstName + " " + lastName，结果 Service 层误用这个方法做业务判断；或者把 createTime（Long 类型）直接塞进 VO，让前端自己格式化，导致时间显示不一致。
立即学习“Java免费学习笔记（深入）”；
- VO 可以有
formattedCreateTime字段，值是"2024-05-20 14:30"这种字符串 - Entity 绝对不能有这类字段，也不能重写
toString()做展示逻辑 - 兼容性注意：如果用 Lombok 的
@Data，别给 Entity 加@ToString，避免日志打印时触发懒加载异常
为什么 DTO 不能直接用 Lombok 的 @Builder 构建
因为 @Builder 默认生成的是全参构造器 + 链式调用，但 DTO 最常被 JSON 框架（如 Jackson）反序列化，而 Jackson 默认依赖无参构造器 + setter。如果 DTO 只有 @Builder 没有 @NoArgsConstructor，就会报 Cannot construct instance of XXX: no String-argument constructor/factory method 错误。
更隐蔽的问题是：用 MyDTO.builder().id(1L).name("a").build() 在单元测试里看着很爽，但一旦 DTO 字段变多、嵌套变深，这种构建方式会掩盖“哪些字段是必填、哪些可为空”的契约意图。
- 正确姿势：DTO 必须显式加
@NoArgsConstructor（Jackson 需要），再按需加@AllArgsConstructor或@RequiredArgsConstructor - 如果要用 Builder 模式，优先选静态工厂方法，比如
public static UserDTO from(UserEntity entity)，语义更清晰 - 别在 DTO 里用
@Builder.Default设默认值，这会让 API 文档（如 Swagger）无法准确推断字段是否可空
MapStruct 自动映射 DTO 和 Entity 时最常漏的三件事
MapStruct 能省掉手写 set/get，但默认行为很容易让你掉坑里：它不会自动处理日期格式转换、枚举映射、集合嵌套展开。这些地方一漏，线上就出脏数据或空指针。
比如 UserEntity.status 是 Integer（数据库存 0/1），而 UserDTO.status 是 StatusEnum，MapStruct 默认根本不转，直接赋 null。
- 日期必须显式声明：
@Mapping(source = "createTime", target = "formattedTime", dateFormat = "yyyy-MM-dd HH:mm") - 枚举映射要配
@ValueMapping或自定义@Mapper(uses = StatusConverter.class) - 集合字段如
List<orderentity></orderentity>→List<orderdto></orderdto>，得加@IterableMapping(qualifiedByName = "toOrderDTO")，否则编译不过
复杂点在于：DTO 层级一深，比如 UserDTO 包含 ProfileDTO，ProfileDTO 又含 AddressDTO，这时候每个中间层都要单独写 Mapper 接口，少一个，运行时就 NPE。没人会真去手动测所有嵌套路径，所以最容易被忽略的其实是映射链的完整性验证——建议在 CI 里加个 MapStruct 编译检查任务，确保所有 @Mapping 都被覆盖。
