持久化实体类是否可直接作为请求体参数？对应最佳实践是什么？

核心结论 #

直接将JPA持久化实体作为@RequestBody的接收参数属于不良实践，绝大多数需要长期维护的业务项目中，单独定义DTO、在Service层完成DTO到持久化实体映射的方案更优。

直接使用持久化实体的弊端 #

• 安全风险高：持久化实体的所有可写字段都可以被前端传入的参数赋值，哪怕是is_deleted、user_role这类不允许普通用户修改的敏感字段，只要前端恶意传参就会被直接写入数据库，极易引发数据安全问题。
• 架构耦合严重：持久化实体是和数据库表结构强绑定的，一旦表结构调整（比如新增/删除字段、修改字段名），对外的接口入参出参也会跟着变，会直接影响对接的前端或第三方系统；反过来如果接口需要新增临时参数（比如不需要存库的前端透传字段），修改实体又会污染持久层设计，长期迭代后代码会变得非常难维护。
• 序列化易出故障：JPA实体常带有代理类、懒加载属性，还有可能存在双向关联的引用关系，直接作为接口入参或返回值的话，很容易出现懒加载未初始化抛异常、循环引用导致序列化失败的问题，需要额外加很多序列化配置，反而增加冗余代码。
• 校验逻辑无法复用：不同接口对同一个实体的校验规则往往不同，比如新增Book接口要求id为空、更新接口要求id不为空，直接在实体上加校验注解根本没法适配多场景的校验需求，最后只能写一堆零散的手动校验逻辑，维护成本很高。

使用DTO映射方案的优势 #

• 架构解耦：DTO只负责对外接口的参数定义，持久层和接口层的迭代完全独立，数据库表结构调整不会影响对外接口的兼容性，接口调整也不需要随便修改表结构，符合单一职责的设计原则。
• 场景适配灵活：同一个持久化实体可以对应多个不同场景的DTO，比如新增用BookCreateDTO、更新用BookUpdateDTO、查询返回用BookDetailDTO，每个DTO只保留当前场景需要的字段，没有冗余。
• 安全性强：DTO只开放允许前端传入的字段，哪怕持久层有敏感字段，前端恶意传参也不会被赋值到实体，从根源上避免参数篡改的风险。
• 校验逻辑清晰：不同场景的校验规则可以直接写在对应DTO上，互不干扰，也不会污染持久层实体的代码。

例外场景 #

如果是个人开发的小工具、内部使用且迭代频率极低、接口和表结构完全一致的项目，直接使用持久化实体也可以，毕竟额外定义DTO和映射逻辑也会增加少量开发成本，可根据项目实际情况取舍。

内容的提问来源于stack exchange，提问作者Nahuel Giani