面经策

Spring 中的 @RequestBody 和 @ResponseBody 注解的作用是什么？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

@RequestBody 和 @ResponseBody 处理的是 HTTP 报文与 Java 对象之间的序列化/反序列化：

  • @RequestBody：把请求体（JSON/XML）反序列化成方法参数对象。用在 POST/PUT 的请求体上，一个方法只能有一个（请求体只能读一次）；
  • @ResponseBody：把方法返回值序列化成 JSON 写入响应体，而不是跳转视图。@RestController = @Controller + @ResponseBody，前后端分离项目的默认选择。

配套的还有 HttpMessageConverter 机制——具体怎么转（Jackson、Fastjson、Protobuf）由它决定，统一日期格式、Long 转字符串防前端精度丢失、脱敏序列化都挂在这里定制。

业务架构视角我关注三点：

  1. API 契约管理：请求/响应 DTO 是对外契约，字段变更要遵守兼容性纪律（只加不删、语义不漂移），配合 OpenAPI 文档自动生成，跨团队协作才顺畅；
  2. 入参校验前移：@RequestBody 搭配 @Validated，脏数据进门即拒，保护下游服务与数据库；
  3. 大报文风险：反序列化是有成本的，超大 JSON（几 MB）会拖垮吞吐，涉及批量数据应引导调用方走分页或文件通道。

一句话：这两个注解是 REST API 的数据搬运开关，背后的契约纪律和序列化治理才是架构师要抓的重点。

🏗 系统架构师 ​

作用：

  • @RequestBody：请求体经 HttpMessageConverter 反序列化成对象（默认 Jackson），一个请求体只能绑定一次；
  • @ResponseBody：返回值不走视图解析，直接序列化写回；@RestController 即 @Controller 加 @ResponseBody。

背后的架构设计：内容协商（Content-Type/Accept）决定使用哪个转换器——这是 MVC 对「表现与资源分离」的实现，同一 Handler 可服务 JSON、XML、Protobuf 多种表示。

生产实践：

  1. 大报文风险：默认全量内存反序列化，几十 MB 的数组请求会打爆堆——入口层限制 Content-Length，必要时流式处理；
  2. 序列化契约要锁定：Jackson 全局配置（日期格式、Long 精度、未知字段策略）由平台 starter 统一收口，避免各服务行为漂移；
  3. 对外 API 加版本与兼容约束：字段只增不删，序列化行为变更必须灰度——body 契约一旦发布就是公共承诺。

💻 全栈开发专家 ​

@ResponseBody：返回值不走视图解析，经 HttpMessageConverter 序列化写回响应体；@RequestBody：请求体反序列化成参数对象。@RestController = @Controller + @ResponseBody，前后端分离标配。

java
@RestController
@RequestMapping("/api/orders")
public class OrderController {
    @PostMapping
    public Result<OrderVO> create(@RequestBody @Valid OrderCreateReq req) {
        return Result.ok(orderService.create(req));   // 自动 Jackson 序列化
    }
}

链路：RequestResponseBodyMethodProcessor → 按 Content-Type 匹配 MappingJackson2HttpMessageConverter → Jackson 读写。

生产必配 Jackson 全局格式，否则全是隐坑：

yaml
spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8
    default-property-inclusion: non_null

坑清单：日期不配格式输出时间戳或 ISO 串，前端对不上；non_null 避免 null 刷屏；反序列化失败（类型不匹配）返回 400，全局异常处理器接 HttpMessageNotReadableException 转友好提示；敏感字段序列化要 @JsonIgnore——安全审计专门扫这个。