POJO是无框架依赖的普通Java对象，非角色而是设计状态；DTO用于跨层数据传输，VO专用于视图渲染；Entity绝不直接返回前端，需通过DTO/VO转换隔离。
POJO 是什么，为什么它不等于 DTO 或 VO
POJO（Plain Old Java Object）只是个“普通 Java 对象”——没继承特定父类、没实现特殊接口、没依赖框架注解。它本身**不是一种角色**，而是一种“无侵入性”的设计状态。你写一个只有 private String name 和对应 getName()/setName() 的类，它就是 POJO；但这个类到底是 DTO 还是 VO，取决于它**在代码里实际怎么用**。
常见错误现象：NullPointerException 频发，或序列化失败，往往是因为把本该是 DTO 的类当成 Entity 直接塞进 MyBatis 查询结果，而它缺了 @Id 或字段名和数据库列不匹配。
- POJO 是“形态”，DTO/VO/Entity 是“职责”——同一个 POJO 类可被同时用作 DTO 和 VO，只要字段够用、语义不冲突
- 加了
@Data（Lombok）或@Entity就不再是纯 POJO，但仍是合法的 Entity 或 DTO 实现 - Spring Boot 2.6+ 默认禁止循环依赖，如果 VO 里嵌套了含 Service 引用的 Entity，启动直接报
BeanCurrentlyInCreationException
DTO 和 VO 在分层中到底谁该出现在哪一层
DTO（Data Transfer Object）专用于**跨进程/跨模块数据搬运**，比如 Controller 接收前端 JSON 时用的参数类，或 Feign 调用远程服务时定义的请求体；VO（View Object）只服务于**当前应用的视图层**，比如 Thymeleaf 模板渲染需要的聚合字段（userName + "（VIP）"），或 Admin 页面表格要展示的“状态标签”字符串。
典型误用场景：把 VO 直接当 DTO 传给 OpenFeign 客户端，结果对方服务反序列化失败——因为 VO 里有 statusLabel 这种计算字段，对方根本没有这个字段。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- Controller 层入参用 DTO，出参用 VO（面向前端）或 DTO（面向其他微服务）
- Service 层内部严禁暴露 VO；VO 应由 Controller 或专门的 Assembler 组装
- DTO 字段必须与协议强一致（如 Swagger 文档、JSON Schema），VO 字段可自由增删，不进 API 文档
Entity 和 DTO 字段不一致时，手动 set 还是用 MapStruct
字段少、映射简单（userDO.getName() → userDTO.setRealName()）时，手写 set 更快也更可控；但字段超过 5 个、存在嵌套对象、或需统一做空值转默认值（如 null → "-" ），硬编码极易漏改、难维护。
MapStruct 编译期生成代码，性能接近手写，但要注意：它默认按字段名匹配，userId → id 这种命名差异必须显式用 @Mapping(target = "id", source = "userId") 声明，否则编译通过但运行时字段为 null。
- Entity 到 DTO 的转换不要放在 Entity 类里加
toDTO()方法——这违反单一职责，且导致 JPA Entity 持有无关逻辑 - 避免用
BeanUtils.copyProperties()：它靠反射，字段类型不一致会静默失败（如String赋值给LocalDateTime），且无法处理嵌套 - MapStruct 的
@Mapper(componentModel = "spring")必须加，否则 Spring 找不到 Bean，注入时报No qualifying bean
为什么 Entity 不该直接返回给前端
Entity 通常带 JPA 注解（@Table、@Column）、可能含懒加载集合（getOrders()）、甚至关联了 User 实体的 passwordHash 字段——一旦被 Jackson 序列化，要么抛 LazyInitializationException，要么泄露敏感字段。
更隐蔽的问题：Entity 字段名常绑定数据库设计（如 usr_nm），而前端需要的是语义清晰的 username；强行用 @JsonProperty("username") 在 Entity 上，会让 DAO 层代码承担表现层契约，后续改库表字段就牵一发而动全身。
- Entity 只在 DAO 和 Service 内部流转，绝不越过 Service 边界
- 即使项目小，也建议用单独 DTO 类，哪怕字段名和 Entity 完全一样——这是层之间的“缓冲垫”，不是冗余
- Jackson 的
@JsonIgnore加在 Entity 上治标不治本，不如让 Entity 彻底不见光
