**口诀 ：“上来 Form，下去 VO，中间 DTO，持久 Entity，别混在一起就舒服。”** 其中最容易混淆的就是 DTO（Data Transfer Object）和 VO（View Object，也常叫 VO/ViewModel）。 >[info]一句话先给出结论： DTO 面向“服务间、进程间”的数据搬运；VO 面向“前端页面/接口渲染”的数据呈现。 二者诞生的目的、进化方向、字段取舍、变更频度都不一样，因此不要混用。 下面把 Java（及 Spring 全家桶）项目里**最常见的“数据对象”**按**出现层级、主要用途、命名惯例**一张表列清，方便你“对号入座”。 （从上到下 ≈ 用户请求 → 持久化 → 响应用户） | 名称 | 出现位置 | 典型后缀 | 核心职责 | 常见误区 | |---|---|---|---|---| | VO / ViewObject | 控制层 → 前端 | XxxVO / XxxPageVO | 只装“当前页面/接口”需要展示的数据，字段随 UI 变，可脱敏、可合并、可裁剪。 | 当成 DTO 直接远程调用，导致大字段泄露。 | | DTO | 服务层 ↔ 服务层（含开放 API） | XxxDTO / XxxReqDTO / XxxRespDTO | 跨进程、跨服务一次性搬运数据，字段“多而全”，兼顾序列化性能与版本兼容。 | 把数据库实体直接当 DTO 返回，造成胖接口。 | | Form / Param | 控制层入参 | XxxForm / XxxQuery | 接收前端表单、查询参数，只做“入参校验”，字段与前端请求一一对应。 | 与 DTO 混用，导致校验注解到处飞。 | | Entity / PO | DAO 层 | XxxEntity / XxxPO | 与数据库表字段 1:1 映射，生命周期随事务，绝不往外传。 | 直接序列化给前端，暴露表结构甚至密码盐。 | | BO / BusinessObj | 领域内（可选） | XxxBO | 聚合多表、多服务后的“充血”业务对象，含行为，用于复杂领域逻辑。 | 项目没做 DDD 也硬上 BO，最后变成万能贫血对象。 | | DO / DataObj | 老派叫法，等价 Entity | —— | 同 Entity，新项目建议统一叫 Entity 或 PO。 | 容易与 BO、DTO 缩写混淆。 | | AO / AppObj | 非常小众，阿里部分老规范 | XxxAO | 一次“应用服务”维度组装的值对象，介于 BO 与 DTO 之间，普通项目可忽略。 | 没团队规范就别自创，维护者看不懂。 | | Query / Criteria | DAO 层入参 | XxxQuery / XxxCriteria | 专装动态 SQL 查询条件，字段只放分页、筛选、排序，解耦 Mapper 入参。 | 把 Entity 当查询条件，导致空值字段也拼进 SQL。 | | POJO | 通称 | —— | 以上所有本质都是 POJO，只是按“职责”再细分。 | 在文档里写“用 POJO 接收”等于没说。 | 一张图速记（请求流向） ``` 前端 HTTP 请求 ↓ JSON Controller ← XxxForm / XxxQuery（校验入参） ↓ 转换 Service ← XxxDTO（远程或本地服务间） ↓ 转换 DAO ← XxxEntity / PO（DB 映射） ↓ SQL 数据库 ``` 返回路径 ``` 数据库 ↓ DAO → XxxEntity ↓ 组装 Service → XxxDTO / XxxBO ↓ 裁剪/脱敏 Controller → XxxVO / XxxPageVO ↓ JSON 前端 ```