一次由 RestTemplate 引发的 Connection reset被 XML 截胡的请求体一行balancedRestTemplateSwitchfalse把开关切到直连模式后OR-Tools 服务立刻Connection reset。排查绕了 Content-Type、转换器、拦截器、自动装配一圈最后发现根因藏在 SpringRestTemplate默认转换器列表的排序里。本文完整记录这次定位过程。一、现象切换到开发环境直连模式balancedRestTemplateSwitchfalse后调用 OR-Tools/solve接口立即抛异常2026-07-20 11:06:24.075 [Add-Async-Thread-9] ERROR ... 调用ORTools异常: org.springframework.web.client.ResourceAccessException: I/O error on POST request for http://xxx:30080/solve: Connection reset; nested exception is java.net.SocketException: Connection reset关键线索藏在请求日志里Http Request | URL http://xxx:30080/solve, ReqMethod POST, Headers { Accept[application/xml, text/xml, application/json, application/cbor, application/*xml, application/*json], Content-Length[133857], Content-Type[application/xml;charsetUTF-8] }两个异常点Content-Type 居然是application/xml—— 我们明明想发 JSONContent-Length 133857—— 比正常 JSON 请求大了一倍多Connection reset不是SocketTimeoutException也不是 4xx —— 说明连接在协议层就被断开了没走到业务逻辑二、调用链路定位先看代码结构。调用 OR-Tools 的入口是// RestTemplateUtils.javapublicstaticObjectpostForORModel(RestTemplaterestTemplate,Stringurl,ObjectrequestEntity)throwsException{ResponseEntityRespOutputresprestTemplate.postForEntity(url,requestEntity,RespOutput.class);...}注意requestEntity是裸的ReqInputPOJO没有被HttpEntity包裹没有显式设置 Content-Type。RestTemplate 的来源// ScoreToolMethod.javaValue(${balancedRestTemplateSwitch:true})privatebooleanbalancedRestTemplateSwitch;publicRestTemplategetActiveRestTemplate(){returnbalancedRestTemplateSwitch?balancedRestTemplate:restTemplate;}两个 Bean 的定义// RestTemplateConfig.javaBean(balancedRestTemplate)LoadBalancedpublicRestTemplateloadBalancedRestTemplate(){RestTemplaterestTemplatenewRestTemplate();restTemplate.setMessageConverters(buildMessageConverters());// ← 配了 JSON 转换器restTemplate.setInterceptors(Collections.singletonList(newRequestHeaderInterceptor()));restTemplate.setRequestFactory(buildRequestFactory());returnrestTemplate;}Bean(plainRestTemplate)publicRestTemplateplainRestTemplate(){returnnewRestTemplate(buildRequestFactory());// ← 一行流啥都没配}问题已经浮现plainRestTemplate只传了RequestFactory没有配messageConverters也没有配拦截器。三、为什么请求体被发成了 XML这是整件事的核心。3.1 Spring 默认转换器列表的排序陷阱new RestTemplate()无参构造器装配转换器时顺序是固定的ByteArrayHttpMessageConverter StringHttpMessageConverter ResourceHttpMessageConverter SourceHttpMessageConverter AllEncompassingFormHttpMessageConverter MappingJackson2XmlHttpMessageConverter ← classpath 有 jackson-dataformat-xml 就加 MappingJackson2HttpMessageConverter ← jackson-databind永远在 XML 之后 MappingJackson2CborHttpMessageConverter ← classpath 有 jackson-dataformat-cbor 就加 ...XML 转换器排在 JSON 转换器前面。这是一个很容易被忽略的默认行为。3.2 转换器选择逻辑RestTemplate.postForEntity内部会创建HttpEntityRequestCallback在doWithRequest里选转换器// AbstractHttpMessageConverter.canWriteprotectedbooleancanWrite(MediaTypemediaType){if(mediaTypenull||getSupportedMediaTypes().isEmpty()){returntrue;// ← 关键分支}for(MediaTypesupported:getSupportedMediaTypes()){if(supported.isCompatibleWith(mediaType)){returntrue;}}returnfalse;}当请求体是 POJO 且没有显式声明 Content-Type时mediaType nullcanWrite直接返回true。于是HttpEntityRequestCallback按列表顺序遍历第一个能处理 POJO 的转换器胜出。由于 XML 转换器排在前面且MappingJackson2XmlHttpMessageConverter用 Jackson 的 XML 序列化器能处理任意 POJO所以它截胡了把ReqInput序列化成 XML 字节流写入 body顺手把自己的默认 MediaType 写进 Content-Type 头 →application/xml;charsetUTF-83.3 为什么 classpath 里会有 jackson-dataformat-xml日志的 Accept 头是铁证Accept[application/xml, text/xml, application/json, application/cbor, application/*xml, application/*json]出现application/xml、text/xml、application/*xml证明MappingJackson2XmlHttpMessageConverter已注册出现application/cbor证明MappingJackson2CborHttpMessageConverter也在。这两个依赖是通过公司内部 BOMyumchina-spring-boot-dependencies传递进来的开发者在写plainRestTemplate时根本没意识到它们的存在。3.4 对比 balancedRestTemplate 为什么是 JSONrestTemplate.setMessageConverters(buildMessageConverters());buildMessageConverters()只返回[StringHttpMessageConverter, MappingJackson2HttpMessageConverter]直接替换掉了默认列表。XML/CBOR 转换器都不存在 → 只能选 JSON →Content-Type: application/json。这就是为什么生产环境balancedRestTemplateSwitchtrue一直没事一切到直连模式就炸。四、为什么拦截器没救场项目里有个RequestHeaderInterceptor第 27 行明明强制设置了 Content-TypepublicClientHttpResponseintercept(HttpRequestrequest,byte[]body,ClientHttpRequestExecutionexecution){HttpHeadersheadersrequest.getHeaders();headers.set(X-Request-Id,UUID.randomUUID().toString());headers.set(Content-Type,application/json;charsetUTF-8);...}但plainRestTemplate压根没注册这个拦截器所以它不生效。即便注册了也救不了——核心是执行时序postForEntity → HttpEntityRequestCallback.doWithRequest() ① 选转换器 序列化 body 写 Content-Type → request.execute() ② 进入 InterceptingClientHttpRequest → RequestHeaderInterceptor.intercept() ③ 此时 body 已是字节只能改 header 值 → 真正发送① 这一步在拦截器之前执行。body 已经被 XML 转换器序列化成字节流了。③ 这一步即便把 Content-Type 改成application/jsonbody 里那串 XML 字节也不会变成 JSON——只会造成Header 说是 JSONbody 实际是 XML的更隐蔽 bug。结论拦截器无法影响用哪个转换器序列化 body它来得太晚。五、那个我没注册的拦截器哪来的排查过程中发现一条不是我写的日志com.yumchina.architecture.framework.starter.web.interceptor.client .PrintReqResponseLog4ClientInterceptor handlerRequest 84 - Http Request | ...项目代码里全局搜索PrintReqResponseLog4ClientInterceptor零匹配。它是公司框架 starter 自动注册的。链路如下1. Starter 的META-INF/spring.factoriesorg.springframework.boot.autoconfigure.EnableAutoConfiguration\ com.yumchina.architecture.framework.starter.web.config.YumWebAutoConfiguration,\ com.yumchina.architecture.framework.starter.web.config.YumRestTemplateConfiguration,\ ...Spring Boot 启动时自动加载YumRestTemplateConfiguration无需手动注册。2.YumRestTemplateConfiguration注册了一个BeanPostProcessorBeanpublicYumRestTemplateBeanPostProcessoryumRestTemplateBeanPostProcessor(){...}3.YumRestTemplateBeanPostProcessor拦截所有RestTemplateBean它的postProcessAfterInitialization会判断bean instanceof RestTemplate然后统一增强——典型做法就是往restTemplate.getInterceptors()里追加PrintReqResponseLog4ClientInterceptor。也就是说容器里每一个RestTemplate类型的 Bean包括plainRestTemplate和balancedRestTemplate在初始化完成后都会被框架统一挂上日志拦截器。这是 Spring Boot 生态里“框架统一增强所有 RestTemplate”的标准套路。这条拦截器打印的日志反而成了我们验证修复是否生效的关键证据。六、服务端为什么是 Connection reset 而不是 400OR-Tools 的/solve服务默认只声明收 JSON。收到 133KB 的application/xmlbody 时要么解析层在读完 header 后就拒绝直接 close socket要么网关/反向代理nginx/ingress在 Content-Type 校验阶段就 reset这两种都不会走完 HTTP 协议正常返回 4xx而是直接断 TCP。客户端看到的就是java.net.SocketException: Connection reset而不是400 Bad Request。这也解释了为什么请求只发了 80ms 就被 reset——根本没到业务逻辑是入口层就拒了。七、根因复盘整个事故是三个因素叠加的结果层原因编码plainRestTemplate偷懒省了setMessageConverters与balancedRestTemplate配置不对称框架Spring 默认转换器列表里 XML 排在 JSON 前且 classpath 误带了jackson-dataformat-xml触发balancedRestTemplateSwitchfalse切到直连分支潜伏 bug 被激活RestTemplateConfig.java是 5 天前一次代码重构提交里新建的plainRestTemplate的写法从创建那一刻起就是一行return new RestTemplate(buildRequestFactory());。平时走负载均衡分支balancedRestTemplateSwitchtrue一直没事bug 潜伏了 5 天直到开发联调切到直连模式才复现。这是典型的配置不对称缺陷两个做同一类事情的 Bean一个严一个松。开发者把plainRestTemplate当成开发环境凑合用的简化版以为用默认配置就够了于是省掉了转换器和拦截器。八、修复方案与验证8.1 根因修复给 plainRestTemplate 补齐配置Bean(plainRestTemplate)publicRestTemplateplainRestTemplate(){RestTemplaterestTemplatenewRestTemplate(buildRequestFactory());// 配置消息转换器支持 JSON与 balancedRestTemplate 保持一致restTemplate.setMessageConverters(buildMessageConverters());// 配置请求拦截器统一添加 Header强制 Content-Type 为 application/jsonrestTemplate.setInterceptors(Collections.singletonList(newRequestHeaderInterceptor()));returnrestTemplate;}8.2 纵深防御postForORModel 显式声明 Content-TypepublicstaticObjectpostForORModel(RestTemplaterestTemplate,Stringurl,ObjectrequestEntity)throwsException{HttpHeadersheadersnewHttpHeaders();headers.setContentType(MediaType.APPLICATION_JSON_UTF8);HttpEntityObjecthttpEntitynewHttpEntity(requestEntity,headers);ResponseEntityRespOutputresprestTemplate.postForEntity(url,httpEntity,RespOutput.class);...}这是在转换器选择阶段就告诉 RestTemplate “我要 JSON”让canWrite(type, application/json)的兼容性检查把 XML 转换器筛掉。即便以后有人新建 RestTemplate 忘了配转换器也不会再误发 XML。8.3 验证修复后同一拦截器打印的日志Headers { Accept[application/json, application/*json], X-Request-Id[a61cf377-6a35-42e4-95e4-d4c540436743], Content-Length[66438], Content-Type[application/json;charsetUTF-8] }字段修复前修复后Content-Typeapplication/xml;charsetUTF-8application/json;charsetUTF-8Acceptapplication/xml, text/xml, application/json, application/cbor, ...application/json, application/*jsonContent-Length13385766438X-Request-Id无a61cf377-...Accept只剩 JSON → XML/CBOR 转换器已被裁掉Content-Type是 JSON → 转换器选择阶段命中了 JacksonX-Request-Id出现 →RequestHeaderInterceptor也已挂上Content-Length从 133KB 降到 66KB → 正是 XML→JSON 的体积差修复完全生效。九、补充buildMessageConverters 的作用修复后有人问既然显式声明 Content-Type 就能解决 reset为什么还要补buildMessageConverters()它解决的不是这次事故而是衍生问题9.1 防止其他调用点裸传 POJOpostForORModel现在显式声明了 Content-Type但plainRestTemplate可能被其他地方复用。如果某个调用点像原来的postForORModel那样裸传 POJO没 HttpEntity、没 Content-TypemediaType null分支又会触发 XML 截胡。裁掉 XML 转换器后无论调用点是否声明 Content-Type都不可能命中 XML。9.2 清理 Accept 头默认列表里所有转换器的 supportedMediaTypes 都会被拼进 Accept 头修复前 Accept[application/xml, text/xml, application/json, application/cbor, ...] 修复后 Accept[application/json, application/*json]严格的服务端会按 Accept 做 content negotiation可能返回 406日志暴露内部依赖能看到 classpath 里有 jackson-dataformat-xml/cbor网关/WAF 可能对异常 Accept 做拦截9.3 配置对称避免“一个 Bean 严、一个 Bean 松”的认知陷阱。配置对称后两个 Bean 行为只差LoadBalanced维护时心智负担小。9.4 Accept 的拼接机制RestTemplate内部走AcceptHeaderRequestCallback.doWithRequest针对响应类型 RespOutput.class 遍历 messageConverters 列表 对每个 converter 调 canRead(RespOutput.class, null) 返回 true 的把它的 getSupportedMediaTypes() 累加进 Accept 最后 setAccept(累加结果)buildMessageConverters()返回的两个转换器转换器supportedMediaTypessupports(RespOutput.class)是否进 AcceptStringHttpMessageConverter[text/plain, */*]clazz String.class→ false❌MappingJackson2HttpMessageConverter[application/json, application/*json]true✅String 转换器只认String.classRespOutput不是 String被跳过 →text/plain、*/*不进 Accept。Jackson JSON 转换器对任意 POJO 返回 true → 它的[application/json, application/*json]进 Accept。XML/CBOR 转换器根本不在列表里所以它们的 MediaType 自然消失。一句话Accept 头 所有能反序列化响应类型的转换器的 supportedMediaTypes 之和。十一、彩蛋为什么旧分支 feature/qianwen-x-K 没出问题排查到根因后一个自然的疑问是postForORModel裸传 POJO 的写法在重构前就存在了为什么旧分支feature/qianwen-x-K一直没事对比两个分支的代码feature/qianwen-x-KScoreToolMethod里Autowired private RestTemplate restTemplate;按类型注入无Qualifier无开关Bean 定义在HttpClientConfig.java:50重构后Qualifier(plainRestTemplate)balancedRestTemplateSwitch开关Bean 定义在RestTemplateConfig.java两个分支的postForORModel写法完全一致都是裸传 POJO、没声明 Content-Type。差异在 RestTemplate Bean 的创建方式上。11.1 旧分支的 RestTemplate 创建方式// feature/qianwen-x-K HttpClientConfig.javaComponentpublicclassHttpClientConfig{AutowiredRestTemplateBuilderrestTemplateBuilder;// ← Spring Boot 注入BeanpublicRestTemplaterestTemplate(){RequestConfigrequestConfigRequestConfig.custom().setSocketTimeout(socketTimeout).setConnectionRequestTimeout(connectionRequestTimeout).setConnectTimeout(connectTimeout).build();CloseableHttpClienthttpClientHttpClientBuilder.create().setDefaultRequestConfig(requestConfig).setMaxConnTotal(maxConnTotal).setMaxConnPerRoute(maxConnTotal).build();ClientHttpRequestFactoryclientHttpRequestFactorynewHttpComponentsClientHttpRequestFactory(httpClient);returnrestTemplateBuilder.requestFactory(()-clientHttpRequestFactory).build();// ← 关键走 RestTemplateBuilder}}11.2 重构后的 RestTemplate 创建方式// 重构后: RestTemplateConfig.javaBean(plainRestTemplate)publicRestTemplateplainRestTemplate(){returnnewRestTemplate(buildRequestFactory());// ← 直接 new绕开 Builder}11.3 决定性差异转换器来源不同feature/qianwen-x-K没出问题重构后plainRestTemplate出问题创建方式restTemplateBuilder.build()new RestTemplate(buildRequestFactory())转换器来源Spring Boot 的HttpMessageConvertersBeanRestTemplate构造器硬编码列表XML 转换器不存在存在且排在 JSON 前11.4 为什么RestTemplateBuilder.build()不会出问题RestTemplateBuilder.build()内部会去拿 Spring Boot 自动装配的HttpMessageConvertersBean。这个 Bean 由HttpMessageConvertersAutoConfiguration创建它只显式注册这些转换器ByteArrayHttpMessageConverterStringHttpMessageConverterResourceHttpMessageConverterMappingJackson2HttpMessageConverterJSONGson / JSON-B视依赖而定关键Spring Boot 的自动装配从不注册MappingJackson2XmlHttpMessageConverter这个 Bean哪怕 classpath 上有jackson-dataformat-xml。所以RestTemplateBuilder组装出来的 RestTemplate转换器列表里根本没有 XML 转换器。POJO 裸传进去只能命中 Jackson JSON 转换器 → 序列化成 JSON。11.5 为什么new RestTemplate()会出问题new RestTemplate()无参构造器绕开 Spring Boot 的HttpMessageConverters自己硬编码装配转换器直接探测 classpath// RestTemplate 源码Spring FrameworkpublicRestTemplate(){this.messageConvertersnewArrayList();this.messageConverters.add(newByteArrayHttpMessageConverter());this.messageConverters.add(newStringHttpMessageConverter());this.messageConverters.add(newResourceHttpMessageConverter());...if(jackson2XmlPresent){this.messageConverters.add(newMappingJackson2XmlHttpMessageConverter());// XML 先加}if(jackson2Present){this.messageConverters.add(newMappingJackson2HttpMessageConverter());// JSON 后加}...}classpath 有jackson-dataformat-xml通过 BOM 传递进来→jackson2XmlPresent true→XML 转换器被加入列表且排在 JSON 前面。POJO 裸传进去canWrite(type, null)命中第一个 → XML 转换器截胡。11.6 一句话总结feature/qianwen-x-K用RestTemplateBuilder.build()走 Spring Boot 自动装配的HttpMessageConverters不含 XML 转换器所以裸传 POJO 也只能序列化成 JSON重构后的plainRestTemplate改用new RestTemplate()绕开了自动装配构造器直接探测 classpath 把 XML 转换器加进列表且排在 JSON 前裸传 POJO 就被 XML 截胡。11.7 这是一次典型的“重构引入回归”重构提交569c3a57-15 18:11把 RestTemplate 的创建方式从RestTemplateBuilder.build()改成了new RestTemplate()意图是手动控制配置转换器、拦截器、超时balancedRestTemplate改完后显式调了setMessageConverters(buildMessageConverters())把 XML 转换器裁掉 → 没事plainRestTemplate漏了这一步 →new RestTemplate()的默认列表里 XML 转换器就冒出来了 → 埋雷隐含的教训RestTemplateBuilder.build()和new RestTemplate()不是等价的——前者受 Spring Boot 自动装配庇护HttpMessageConvertersBean 默认不含 XML 转换器后者暴露 Spring Framework 的原生默认行为构造器直接探测 classpathXML 转换器会被加入从前者迁到后者时必须显式处理转换器列表调setMessageConverters(...)裁剪否则会引入“原来没有的新行为”。更稳妥的做法是重构时保留RestTemplateBuilder的使用只在它的基础上.requestFactory(...)、.setConnectTimeout(...)增量配置而不是推倒重来用new RestTemplate()。十二、总结与启示技术启示new RestTemplate()的默认转换器列表有坑XML 排在 JSON 前面classpath 有jackson-dataformat-xml就会触发 POJO 被序列化成 XML。拦截器无法影响转换器选择它在 body 序列化之后才执行改 header 救不了 body。显式声明 Content-Type 是最可靠的兜底它让canWrite走兼容性检查分支把不兼容的转换器筛掉。框架的自动装配会统一增强所有 RestTemplate日志拦截器、指标埋点都是这么挂上的不需要手动注册。工程启示配置要对称两个做同一类事情的 Bean应该共享同一套基础配置只差必要的差异如LoadBalanced。开发环境的“简化版”最容易埋雷生产环境走完整配置一直没事一切到简化配置就炸。bug 不会因为“这是开发环境”就消失只会延迟爆发。潜伏期 切换条件触发时间这次 bug 潜伏了 5 天直到切到直连模式才复现。任何有开关的代码路径都需要在两条路径上都验证过。日志是最好的验证工具框架自动装配的PrintReqResponseLog4ClientInterceptor帮我们直接看到了请求头对比修复前后的 Header 变化修复是否生效一目了然。一行话根因plainRestTemplate没配 JSON 转换器用了 Spring 默认列表默认列表里 XML 转换器排在 JSON 前面postForORModel裸传 POJO 没声明 Content-Type于是请求体被 XML 转换器截胡服务端拒收 XML 直接 reset 连接。