主动写入流对@ResponseBody注解的影响

主动,写入,responsebody,注解,影响 · 浏览次数 : 41

小编点评

## 解释代码逻辑代码案例1和案例2都使用了 `@ResponseBody` 注解，但执行结果却不同。 **案例1**中，如果文件配置参数获取不到，则返回 `msg` 字段，但 `@ResponseBody` 会将 `Map` 类型的返回值直接渲染到 JSON 字符串中，导致无法正常显示错误信息。 **案例2**中，如果文件配置正确，但由于 `@ResponseBody` 的使用，最终的 JSON 字符串格式会根据响应头设置的 `Content-Disposition` 进行处理，导致请求无法成功。 **结论：** * 当 `@ResponseBody` 和 `@RequestMapping` 中都没有设置参数时，执行结果会与直接返回 JSON 字符串类似。 * 当文件配置正确，但缺少相关参数导致请求失败时，`@ResponseBody` 会导致正常渲染，但 JSON 字符串格式会影响响应的显示。 * 最佳方案是：在 `@RequestMapping` 中设置参数，并结合 `@ResponseBody` 在响应 JSON 字符串之前进行格式处理，确保正确显示错误信息。 **建议：** * 在实际开发中，务必对配置参数进行仔细验证，确保所有必要参数都得到正确设置。 * 可以使用 `@ExceptionHandler` 等异常处理机制，捕获 unexpected 错误并提供友好的异常消息提示。

正文

问题回溯

2023年Q2某日运营反馈一个问题，商品系统商家中心某批量工具模板无法下载，导致功能无法使用（因为模板是动态变化的）

商家中心报错（JSON串）：

{"code":-1,"msg":"失败"}

负责的同事看到失败后立即与我展开讨论（因为不是关键业务，所以不需要回滚，修复即可），我们发现新功能模板下载的代码与之前的代码有所不同，恰好之前的功能又可以正常运行，所以同事对现有代码进行改造然后预发布测试完成后再次上线。

其他业务代码：

/**
 * 模板下载
 */
@RequestMapping("/doBatchWareSetAd")
public void doBatchWareSetAd(@RequestParam MultipartFile file, HttpServletResponse response) {
	wareBatchBusiness.doBatchWareSetAd(file, response, getLongOrgCode(), getCurrentUserPin(), getCurrentUserId());
}

问题业务代码：

/**
 * 模板下载
 */
@RequestMapping("/doBatchWareSetAdDemo")
@ResponseBody
public Map<String, Object> doBatchWareSetAd(@RequestParam MultipartFile file, HttpServletResponse response) {
	return wareBatchBusiness.doBatchWareSetAd(file, response, getLongOrgCode(), getCurrentUserPin(), getCurrentUserId());
}

上线的结果是；仍然无法使用。

其实也正常：因为两种代码在预发布都可以正常运行，在线上出错只可能是因为其他原因，只不过我们不了解底层原理，害怕它 "可能" 有问题罢了，最终查询得到的结论是权限系统管理员在线上环境没有给我们配置相应的文件，导致请求为空，导致请求失败。

探索 @ResponseBody 与主动写入流的关系

我们都知道 @ResponseBody 注解可以帮助我们把返回对象转化为JSON，方便展示和交互。

那它到底是如何工作的呢，请看下面的讲解：

代码案例1：

@RequestMapping("/test1")
@ResponseBody
public Map<String, String> test1(HttpServletResponse response) {
    Map<String, String> map = new HashMap<>();
    map.put("1", "1");
    return map;
}

// 响应
JSON报文

跟代码发现其核心处理类为：RequestResponseBodyMethodProcessor.java

方法：org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor#handleReturnValue 会处理其相关返回值。

真正的核心处理方法：org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor#writeWithMessageConverters

关键DEBUG记录如图所示：

后续内容可以想象，肯定还有地方去把流按照指定的HEADER写入，因为和本文无关所以不深究。

再来看代码案例2：

@RequestMapping("/test2")
@ResponseBody
public Map<String, String> test2(HttpServletResponse response) throws IOException {
    Map<String, String> map = new HashMap<>();
    map.put("1", "1");

    response.setContentType("application/vnd.ms-excel");
    response.setHeader("Content-Disposition", String.format(
        "attachment; filename=%s_%s.xls", "Demo", System.currentTimeMillis()));

    OutputStream out = response.getOutputStream();
    out.flush();
    out.close();
    return map;
}

// 响应
提示下载文件

关键DEBUG源码截图：

可以发现Spring对这种方式操作文件流视作异常情况，然后抛出，在后续逻辑中完成整个请求，简单来说就是 @ResponseBody 注解没起到任何作用。

因此答案呼之欲出：当时功能不可用的罪魁祸首就是相关人员没有配置参数导致，与写法没有任何关系。

结论与启发

结论：

我们要相信自己的代码，至少是要相信已经经过测试的代码。
在委托他人或者自己配置环境参数，如权限、ZK等每次都保证预发布和线上同时配置，避免遗漏的情况。

启发：

聊了这么多，那我们这种类似场景的代码应该怎么写？

既然主动写入流会解除@ResponseBody的作用，反之又能发挥它的作用，那我们最佳方案是不是如下所示？

@RequestMapping("/test1")
@ResponseBody
public Map<String, String> test1(HttpServletResponse response) {
    Map<String, String> map = new HashMap();
    if (获取不到文件配置 == true) {
        return map.put("msg", "获取不到文件配置");
    }
    
    response.setContentType("application/vnd.ms-excel");
    response.setHeader("Content-Disposition", String.format(
        "attachment; filename=%s_%s.xls", "Demo", System.currentTimeMillis()));

    OutputStream out = response.getOutputStream();
    out.flush();
    out.close();
    return map;
}

如此一来，当发生预期之外的情况，我们有非常明显的报错提示，当正常时又可以完美实现功能，妙哉（我觉得）~

作者：京东零售柯贤铭

来源：京东云开发者社区转载请注明来源