pojo是不继承父类、不实现框架接口、不依赖注解的纯java对象；entity耦合jpa生命周期管理，po仅作sql映射；推荐统一用userdo命名数据库类，dto用于服务间传输，vo用于前端展示，且均需实现serializable。
POJO不是一种对象，而是一种“不被框架绑架”的写法
POJO（Plain Old Java Object）本质是种编程态度：它不继承特定父类、不实现框架接口、不依赖注解（哪怕@Data也算轻微“污染”）。你写的User类只有private String name和getName()/setName()，没加@Entity、@Component，也没实现Serializable——那它就是POJO。
容易踩的坑：
- 误把带
@Data（Lombok）的类当纯POJO：Lombok生成的toString()和equals()虽方便，但已引入行为，严格来说不算“plain” - 给布尔字段起名
isDeleted：很多序列化框架（如FastJSON、Dubbo）会按JavaBean规范找deleted字段，导致反序列化失败，报错类似Cannot find field 'deleted' - 在POJO里写业务逻辑：比如
User.isValidEmail()——这会让对象变重，破坏分层边界，后续DTO/VO转换时容易漏掉校验逻辑
Entity和PO到底该用哪个？看你的ORM选型
在Spring Boot + JPA项目里，User类上标了@Entity@Table(name="t_user")，它就叫Entity；在MyBatis-Plus项目里，同样这个类可能叫UserPO（Persistent Object），因为MyBatis生态更倾向显式命名PO。
关键区别不在名字，而在职责：
立即学习“Java免费学习笔记（深入）”；
-
Entity通常承担JPA生命周期管理（@PreUpdate、延迟加载、一级缓存等），耦合度高 -
PO在MyBatis中更轻量，只是SQL映射载体，不参与ORM状态管理 - 二者都不该直接暴露给前端或跨服务传输——否则数据库字段改名、加敏感字段（如
passwordSalt）就会立刻影响调用方
实操建议：统一用xxxDO（Data Object）替代Entity或PO，例如UserDO。这是阿里《Java开发手册》推荐写法，语义清晰且不绑定ORM技术栈。
DTO和VO别混着用，它们解决的是不同层的“裁剪焦虑”
DTO是Service层往外“发数据”时用的，目标是减少网络传输量、屏蔽内部结构；VO是Controller层给前端“交差”时用的，目标是适配页面字段、做格式转换（如createTime → "2026-02-11 21:02"）。
典型错误现象：
- 把
UserDTO直接转成JSON返回给前端：一旦DTO里有userPasswordHash或internalStatus字段，就属于信息泄露 - 在VO里塞业务计算逻辑，比如
UserVO.getAgeByBirthDate()：视图层不该承担计算，应由Service层算好再设值 - 用Map代替DTO传参：超过2个查询条件就该封装为
UserQueryDTO，否则IDE无法跳转、单元测试难写、Swagger文档不自动生成
参数差异示例：UserDTO可能含departmentId（供下游服务关联查部门）；UserVO则含departmentName（前端直接展示），不含ID。
命名必须带后缀，且后缀要真实反映用途
禁止出现UserModel、UserObject、UserInfo这种模糊命名——它既不能说明是入参还是出参，也无法判断是否可序列化。
正确姿势（按阿里规范+一线团队验证）：
- 数据库映射类 →
UserDO（DO= Data Object） - RPC/HTTP接口入参 →
UserCreateDTO、UserPageQueryDTO - HTTP响应体 →
UserDetailVO、UserListVO - 领域内业务组装体 →
OrderBO（Business Object），不是所有业务逻辑都得塞进Service方法里
包结构也要配合：按层分包，如com.example.user.domain.entity.UserDO、com.example.user.interfaces.dto.UserDTO、com.example.user.interfaces.vo.UserVO。
最常被忽略的一点：VO和DTO类必须实现Serializable，否则在分布式场景下（如Dubbo泛化调用、Redis缓存VO）会抛NotSerializableException——而这个异常往往只在压测或上线后才暴露。
