Spring Boot 1.5代理服务转发ResponseEntity时请求挂起问题

这个问题我之前也遇到过类似的情况，咱们来一步步拆解原因：

首先，核心问题出在RestTemplate返回的ResponseEntity和Spring MVC自身构造的ResponseEntity在处理逻辑上的差异，具体有两个关键点：

1. 后端API的HttpHeaders与当前服务响应不兼容 #

当你直接返回RestTemplate的ResponseEntity时，它会完整复用后端API返回的所有HttpHeaders，包括Content-Length、Transfer-Encoding这类与响应体传输相关的头。这些头是针对「后端API → 当前服务」这个连接的，并不一定适用于「当前服务 → 客户端」的连接。

举个例子：假设后端API返回的响应体是GBK编码的字符串，Content-Length头记录的是该字符串的GBK字节数。当RestTemplate把它转换成Java的String后，当前服务在返回给客户端时，默认会用UTF-8编码输出，此时实际的字节数和原Content-Length不匹配。客户端收到响应后，会按照Content-Length头的数值等待数据，结果实际收到的字节数不够，就会一直挂起直到超时。

2. 响应体可能与已关闭的连接绑定 #

虽然你指定了响应类型为String.class，但在处理错误状态码（非200）时，结合你的自定义UserErrorHandler，RestTemplate有可能没有完全将响应体读取到内存中——或者说，返回的ResponseEntity中的body是一个与后端连接绑定的流资源（比如InputStreamResource）。当RestTemplate完成请求后，底层的连接会被释放关闭，此时Spring MVC尝试读取这个流时，就会因为流不可用而阻塞，导致客户端一直等待。

而当你重新构造ResponseEntity时：

• 你显式地将body提取为内存中的String，脱离了原连接的绑定；
• Spring MVC会根据当前的body和响应状态码，重新生成适配「当前服务→客户端」连接的HttpHeaders（比如自动计算正确的Content-Length），所以响应能正常发送到客户端，不会出现挂起。

解决方案 #

最稳妥的方式就是像你现在做的那样，重新构造ResponseEntity返回。如果需要复用部分后端API的头信息，可以复制原头后移除或调整可能冲突的字段（比如Transfer-Encoding、Connection），再重新计算Content-Length：

@PostMapping
public ResponseEntity<?> add(@Valid @RequestBody User user) {
    ResponseEntity<String> response = restTemplate.postForEntity(userUrl, user, String.class);
    
    // 复制原头并清理冲突字段
    HttpHeaders newHeaders = new HttpHeaders();
    newHeaders.putAll(response.getHeaders());
    newHeaders.remove(HttpHeaders.TRANSFER_ENCODING);
    newHeaders.remove(HttpHeaders.CONNECTION);
    
    // 基于当前编码重新计算内容长度
    byte[] bodyBytes = response.getBody().getBytes(StandardCharsets.UTF_8);
    newHeaders.setContentLength(bodyBytes.length);
    
    return new ResponseEntity<>(bodyBytes, newHeaders, response.getStatusCode());
}

不过大多数情况下，直接用ResponseEntity.status().body()的方式就足够简单可靠了。

内容的提问来源于stack exchange，提问作者riccardo.cardin