SpringBoot POST接口处理输入流返回时出现No HttpMessageConverter报错问题

1. No HttpMessageConverter for [B异常 #

• 本质原因：[B是JVM对byte[]字节数组类型的内部类签名（直接执行byte[].class.getName()就会输出这个字符串），异常触发是因为RestTemplate在序列化请求体时，遍历已注册的消息转换器列表，没有找到能处理byte[]类型写入逻辑的匹配项。
• 代码配置缺陷：原实现是在RestTemplate默认生成的转换器列表末尾追加自定义的ResourceHttpMessageConverter，没有给该转换器配置字节数组的写入支持，反而因为转换器顺序错位，把原有的ByteArrayHttpMessageConverter的匹配优先级挤到了后面，最终触发类型无匹配的异常。

2. 新增ByteArrayHttpMessageConverter后触发服务端500错误 #

• 三类常见触发场景：
  • 服务端参数绑定失败：原控制器方法直接把InputStream作为裸入参，没有指定对应的消息转换器绑定规则，Spring MVC会尝试用默认的转换器把请求体反序列化为参数对象，因为原始InputStream没有对应的序列化逻辑，直接抛出类型转换异常，最终返回500。
  • 响应输出失败：控制器返回的裸InputStream没有被包装为Spring支持的资源类型，在响应序列化阶段，Spring尝试对流对象做常规Java序列化时失败，触发500。
  • 路由匹配失败：原测试代码没有显式设置请求的Content-Type为application/octet-stream，服务端路由时因为请求头的Content-Type和接口声明的路由规则不匹配，也会触发500。

服务端控制器侧优化 #

替换原控制器的参数接收和返回逻辑，适配Spring的流式传输规则，同时避免大文件全量加载到内存：

@PostMapping(
    value = "/somePath",
    consumes = MediaType.APPLICATION_OCTET_STREAM_VALUE,
    produces = MediaType.APPLICATION_OCTET_STREAM_VALUE
)
public ResponseEntity<InputStreamResource> processData(HttpServletRequest request) throws IOException {
    // 直接从原生request中获取输入流，绕过Spring的参数绑定流程，避免绑定异常
    InputStream rawInputStream = request.getInputStream();
    InputStream processedStream = processor.process(rawInputStream);
    // 把处理后的流包装为Spring原生支持的资源类型，直接通过响应输出流写出，不需要额外的序列化逻辑
    return ResponseEntity.ok()
            .contentType(MediaType.APPLICATION_OCTET_STREAM)
            .body(new InputStreamResource(processedStream));
}

• 关键注意点：
  • 不要直接在方法参数里声明InputStream data作为入参，Spring的参数解析器会优先尝试用消息转换器绑定该类型，容易出现匹配失败问题。
  • 不要把原始InputStream直接作为响应体返回，必须包装为InputStreamResource，否则响应阶段的序列化逻辑会找不到对应处理器。
  • 这套实现下，数兆字节的响应数据全程走流式输出，不会把全量数据加载到JVM内存。

客户端RestTemplate侧优化 #

修正消息转换器的配置逻辑，不要在默认列表末尾追加自定义转换器，直接按优先级初始化完整的转换器列表：

// 按类型匹配优先级初始化转换器，保证字节、流资源、字符串类型的处理逻辑正常
restTemplate.setMessageConverters(List.of(
    new ByteArrayHttpMessageConverter(),
    new ResourceHttpMessageConverter(),
    new StringHttpMessageConverter(StandardCharsets.UTF_8)
));

修正请求构造逻辑：

private ResponseEntity<Resource> request() {
    HttpHeaders headers = new HttpHeaders();
    headers.setAccept(List.of(MediaType.APPLICATION_OCTET_STREAM));
    // 显式设置请求的Content-Type，和服务端接口的consumes配置完全匹配
    headers.setContentType(MediaType.APPLICATION_OCTET_STREAM);

    URI requestUri = UriComponentsBuilder
        .fromHttpUrl(format("http://localhost:%s/%s", serverPort, "/somePath"))
        .build()
        .encode(StandardCharsets.UTF_8)
        .toUri();

    // 直接构造字节数组请求体，不需要包装为泛型InputStream类型，避免类型匹配异常
    HttpEntity<byte[]> requestEntity = new HttpEntity<>("Hello".getBytes(StandardCharsets.UTF_8), headers);
    // 响应类型声明为Resource，利用原生转换器的流处理能力，避免内存全量加载
    return restTemplate.exchange(requestUri, HttpMethod.POST, requestEntity, Resource.class);
}

• 效果说明：这套配置下，请求发送和响应接收全流程都是基于流处理的，消息转换器的匹配逻辑不会出现顺序错位的问题，从根源上解决之前出现的两个异常。

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