持久化新对象时应使用@RequestBody还是@RequestParam接收参数

针对你提到的包含大量复杂对象的业务场景，优先选择使用@RequestBody接收JSON格式的请求体，两种方案的对比和选择原因如下：

两种方案的适用场景对比 #

@RequestBody 方案的优势

• 完美适配复杂对象结构：如果你的业务对象存在嵌套对象、数组、列表等结构，比如User类内嵌Address对象、角色ID列表，JSON可以天然支持多层级的复杂结构，不需要做额外的参数解析。如果用@RequestParam传递复杂结构，需要自己实现大量参数转换逻辑，代码冗余度极高，还容易出现解析错误。
• 可维护性更强：前端传递的参数结构和后端实体类结构一一对应，后续新增、修改字段只需要同步调整实体类即可，不需要改动接口的参数定义，特别适合字段较多的对象提交场景。
• 符合RESTful通用实践：对于创建/更新资源的POST、PUT请求，行业通用规范都是将业务核心参数放在请求体中传递，Query参数一般只用来传递分页、排序、过滤这类控制类参数。
• 开发效率更高：Spring MVC会自动完成JSON字符串到实体类的反序列化，你不需要手动根据零散参数构建对象，直接声明@RequestBody User user即可直接使用实例，还可以无缝对接JSR校验注解，自动完成参数合法性校验。

@RequestParam 方案的适用场景

该方案仅适合参数数量极少（通常2个以内）、结构极其简单的接口，或者GET请求场景（GET请求通常不建议携带请求体，部分网关、代理服务器会直接丢弃GET请求的请求体）。你提到的持久化对象场景通常是POST请求，且存在大量复杂对象，显然不适用该方案。

最佳实践建议 #

你直接按照以下方式定义接口即可：

@PostMapping("/api/user")
public User addUser(@Valid @RequestBody User user) {
    // 直接操作user对象执行业务逻辑
    return userService.save(user);
}

同时给User类加上对应的参数校验注解即可满足大多数场景需求：

class User {
    @NotBlank(message = "用户名不能为空")
    private String name;
    @Email(message = "邮箱格式不正确")
    private String email;
    // 省略getter、setter
}

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