OkHttp

背景 我维护一条三层调用链：网关（超时 200ms）→ 聚合服务 B（OkHttp 调 C 超时 150ms）→ 数据服务 C（Spring Boot + HikariCP maximumPoolSize=20，连接 MySQL 8.0.3

背景 我负责一个聚合服务（Spring Boot 3 + JDK 21 虚拟线程 + OkHttp5 连接池 maxRequests=200/maxRequestsPerHost=50，单机 8C16G，前置 4 实例），核心接口一次请求并

«结论先行：超时不是「让请求成功的开关」，而是「让失败尽快返回的开关」；重试不是救场，而是容量放大器。这两句话是 2025-11-28 那次事故教给我的，代价是 82000 次重试、2300 笔重复订单、8100 条用户工单。下面按「现象

«结论先行：「偶发 Connection reset by peer、重试一次就好、抓包看不到丢包」，十有八九不是网络，而是客户端与服务端的 keep-alive 空闲超时不一致——服务端先关，客户端不知情，复用旧连接发请求，撞上服务端 R

【背景】 订单网关，JDK 21 虚拟线程（spring.threads.virtual.enabled=true）+ Spring Boot 3.2，下游用 OkHttp 4.12 调 3 个内部 HTTP 服务（已从 Feign 迁过来

【背景】 我们有一个网关类服务（Java 17，Spring Boot 3，16C32G），用 OkHttp 3.14 作为 HTTP 客户端，连接池 "ConnectionPool(200, 5min, TimeUnit.MILLISEC