POJO是基础数据容器，无上下文；DTO专为跨层传输设计，精简字段；VO面向前端展示，支持格式化与聚合；PO/DO严格映射数据库表。
分层开发中，POJO、DTO、VO 不是命名游戏，而是职责隔离的体现。关键不在“叫什么”，而在“谁用、在哪用、为什么这么切”。下面从实际协作场景出发，讲清楚怎么定义、怎么区分、怎么避免踩坑。
POJO：最基础的“数据容器”，不带任何上下文
POJO 就是一个干净的 Java 类：只有字段、getter/setter、无继承、不实现特殊接口。它不绑定数据库，也不服务前端，是所有对象的起点。
说明：
- 一个 UserPOJO 可以转成 PO 存进数据库，也可以转成 DTO 传给前端，还能作为 VO 渲染页面——取决于你把它放在哪一层、怎么用
- 不要在 POJO 里加业务方法、校验逻辑或注解（如 @TableField），这些属于具体角色的职责，不是 POJO 的事
- 推荐用 Lombok 的 @Data 或 @Setter/@Getter，保持简洁；避免手写冗长的 setter/getter
DTO：专为“跨层传输”设计，字段必须精简且明确
DTO 是 Service 层和 Controller 层之间的“信使”，核心目标是减少传输量、隐藏敏感信息、适配调用方需求。
建议：
- 字段名尽量与前端一致（比如前端要 user_name，就定义为 userName，别硬套数据库下划线）
- 登录请求 DTO 只留 username/password；用户列表返回 DTO 只含 id/nickname/avatar/status；密码、salt、version 等字段一律排除
- 需要组合多个实体时（如订单+用户+地址），直接新建一个 OrderDetailDTO，而不是强行复用某个 POJO
- 务必实现 Serializable，尤其涉及 RPC 或缓存场景
VO：面向“最终展示”，可格式化、可聚合、可裁剪
VO 是后端给前端的最后一道数据封装，服务于具体页面或组件。它可能把日期转成字符串、把状态码转成中文、把头像 URL 拼接完整路径。
注意点：
- VO 不等于“DTO 改个名”。比如 /user/profile 接口返回的 UserVO，字段和格式应完全匹配该页面 UI 需求
- 允许有计算字段（如 fullName = firstName + lastName）、格式化字段（如 createTimeStr = "2026-03-28"）、空安全字段（如 avatarUrl = StringUtils.defaultString(avatar, "/default.png")）
- 不要在 VO 里放 setter 方法——它只用于输出，不接收输入
- 如果前端多个页面共用同一套数据结构，可考虑统一 VO 命名规范，如 UserSummaryVO、UserDetailVO
PO/DO：数据库的“镜像”，字段必须严格对齐
PO（Persistent Object）或 DO（Data Object）是持久层专属对象，唯一使命就是和数据库表一一映射。
实操要点：
- 字段类型必须与数据库一致（如 MySQL 的 DATETIME → LocalDateTime，TINYINT(1) → Boolean）
- 包含 MyBatis-Plus 或 JPA 的注解（@TableId、@TableField、@Column），但仅限 DAO 层可见
- 禁止在 PO 中写业务逻辑、校验、格式转换——这些都该由 Service 或 VO 承担
- 一张表对应一个 PO；视图、联合查询结果不直接用 PO，应定义专门的 QueryDTO 或 ResultVO
