做Java开发和外部系统打交道基本是每天的必修课。对方给你一个接口文档你需要在代码里发起HTTP请求去调用它这几乎是所有业务系统都绕不开的环节。不管是调用第三方支付、对接上游供应商的OpenAPI还是自己系统内部服务之间的数据同步Java生态里发起HTTP请求的方式非常多从JDK自带的HttpURLConnection到后来的java.net.http.HttpClient再到Apache HttpClient、OkHttp、Spring的RestTemplate和WebClient甚至Hutool这种工具库。很多刚入行的朋友在面试时被问到“Java里有哪些发送HTTP请求的方式”脑子里就那么一两个答案实际开发中又容易被各种细节卡住——超时怎么设置、连接池怎么配、响应流要不要关闭、异步调用怎么写。这篇文章就把我这些年实际用过的、踩过坑的几种主流方式完整梳理一遍从用法、原理到适用场景一次性讲透适合正在准备面试的Java工程师也适合那些项目里要选型但拿不准用哪种方案的团队。1. 方案全景梳理Java调用HTTP请求的几种路线1.1 从JDK原生到三方库的演进逻辑Java调用HTTP请求这件事本质上就是“发起连接、组装报文、解析响应”三个动作的组合。最早的时候JDK 1.1就提供了HttpURLConnection这是所有Java开发者最初接触到的HTTP客户端。它的优点是零依赖任何JDK环境里都能直接用但缺点也很明显——API设计偏底层用起来繁琐功能也不够丰富。后面Sun公司又推出了HttpClient就是现在JDK 11里那个java.net.http.HttpClient的前身但早期是作为单独下载的扩展包存在直到JDK 11才正式进入标准库。与此同时Apache基金会和Square公司分别推出了Apache HttpClient和OkHttp这两个优秀的第三方库把一个HTTP客户端该有的东西都补齐了连接池管理、请求重试、HTTP/2支持、拦截器机制、异步调用。Spring生态里又基于这些底层实现封装了RestTemplate和WebClient让开发者在业务代码里能用更少的代码完成调用。所以你会发现这些方案之间不是简单的替代关系而是层层封装的关系理解了这个演进脉络选型的时候心里就有底了。1.2 选型决策的几个关键维度我一直觉得选HTTP客户端没有一个绝对的“最好”只有“在当前场景下最合适”。实际项目里我会从四个维度去权衡。第一是依赖约束如果项目是个老系统还在用JDK 8那JDK 11自带的HttpClient就用不了只能选HttpURLConnection或者第三方库第二是功能需求比如需要连接池复用、需要HTTP/2、需要拦截器做统一鉴权和日志那肯定优先考虑OkHttp或者Apache HttpClient第三是团队技术栈如果项目已经用了Spring那RestController体系里有现成的RestTemplate或者WebClient没必要自己再去引一套底层库第四是易用性和可维护性像Hutool的HttpUtil写起来特别快适合脚本类、工具类的调用但如果搞大型微服务项目我还是建议用更规范、更方便做封装的方案。把这几条列出来对照一下你的选择就清晰了。方案最低JDK版本依赖情况连接池HTTP/2异步支持学习成本HttpURLConnection1.1无有限可调不支持需自己封装线程池低JDK HttpClient11无有内部管理支持原生CompletableFuture中Apache HttpClient8需引入成熟支持有中OkHttp8需引入成熟支持有Call中RestTemplate8需Spring依赖底层实现依赖底层同步可用异步变体低WebClient8需Spring WebFlux依赖底层实现支持原生Reactive中高Hutool HttpUtil8需引入有简单管理不支持不支持极低1.3 我个人的默认推荐这里先亮一下我自己的结论后面每一节再展开细节。如果项目是JDK 11以上的新项目、没有引入任何框架我会直接用JDK自带的HttpClient理由很朴素不需要引入额外依赖功能也够用。如果项目已经用了Spring Boot默认RestTemplate同步场景或者WebClient异步/响应式场景因为和生态结合好后续做拦截器、过滤器都方便。如果项目在JDK 8环境下优先考虑OkHttp它的API设计我觉得是最舒服的链式调用写起来很顺手性能也好。如果只是写个临时脚本、测试代码或者内部小工具那就Hutool一把梭一行代码搞定GET/POST节省的时间非常可观。这套组合拳基本能覆盖我遇到的90%以上的业务场景。2. JDK原生的两条路线HttpURLConnection与HttpClient2.1 HttpURLConnection的基础用法与隐藏的坑很多人觉得HttpURLConnection是老古董了但它在某些场景下依然有价值——比如你不能引任何第三方依赖的极端环境或者你就是想写一段没有任何包袱的示例代码。它的基本用法是这样的public static String doGet(String urlStr, MapString, String headers) throws IOException { URL url new URL(urlStr); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(GET); conn.setConnectTimeout(5000); conn.setReadTimeout(10000); if (headers ! null) { headers.forEach(conn::setRequestProperty); } int code conn.getResponseCode(); if (code 200) { try (BufferedReader reader new BufferedReader(new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) { StringBuilder sb new StringBuilder(); String line; while ((line reader.readLine()) ! null) { sb.append(line); } return sb.toString(); } } else { throw new IOException(HTTP error code: code); } }这段代码里有两个非常容易踩的坑。第一个是连接复用问题HttpURLConnection本身有连接池的概念但默认情况下如果你没有正确调用disconnect()或者没有读完响应流就直接断掉连接是没法复用的。正确的做法是尽量读完整个getInputStream()让连接回到池子里而不是读取了几个字节就异常退出。第二个是超时配置setConnectTimeout和setReadTimeout这两个方法很多人会漏掉尤其是在内网环境里服务一旦假死没有超时的话线程会一直挂在那里最终把线程池打满这个在线上是很严重的事故。还需要注意对于DELETE、PUT这类方法你需要设置conn.setRequestMethod(DELETE)同时如果请求需要带body还得设置setDoOutput(true)否则服务端收不到你的请求体。另外响应编码问题也要小心服务端如果不给你返回charset参数你用UTF-8解码可能乱码这里有经验的做法是先用conn.getContentType()拿一遍看里面有没有charset没有就根据业务约定来。2.2 JDK 11 Httpclient标准库里的现代实践JDK 11正式把java.net.http.HttpClient纳入了标准库这意味着你不需要引入任何第三方依赖就能拥有一个支持HTTP/2、支持异步、API设计更现代的HTTP客户端。我把它的基本用法贴出来import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; public class JdkHttpClientDemo { public static void main(String[] args) throws Exception { HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) .version(HttpClient.Version.HTTP_2) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.example.com/user/123)) .timeout(Duration.ofSeconds(10)) .header(Accept, application/json) .GET() .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body()); } }如果是POST带JSON body的请求只需要把GET()换成下面这段HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.example.com/user)) .timeout(Duration.ofSeconds(10)) .header(Content-Type, application/json) .POST(HttpRequest.BodyPublishers.ofString({\name\:\张三\}, StandardCharsets.UTF_8)) .build();这里有几个细节值得注意。第一HttpClient和HttpRequest都是Builder模式HttpClient的实例是线程安全的可以全局复用不要每个请求都new一个那样会浪费连接资源HttpRequest每次请求都要重新构建因为URI、body这些信息是请求级别的。第二异步调用用的是sendAsync返回值是CompletableFutureHttpResponseT你可以在上面链式调用thenApply、whenComplete来处理响应配合Java 8的CompletableFuture特性写起来比回调舒服很多。第三超时配置有两个层次HttpClient上的connectTimeout只控制建立连接的超时HttpRequest上的timeout控制的是整个请求的完成时间这两个要配合使用不能只设置一个。我在项目里见过只设置了connectTimeout、没设置request timeout的结果服务端响应慢整个请求一直卡着不返回最后只能靠全局链路超时兜底。第四标准的BodyHandlers.ofString()默认按UTF-8解码如果你调用的接口返回的是其他编码需要自己写BodyHandlers.ofInputStream()再手动处理当然绝大多数场景UTF-8是够用的。2.3 JDK原生方案的实际定位虽然JDK自带了可用的HTTP客户端但我在实际项目里直接用它的时候不是特别多尤其是在Spring Boot项目里。原因很简单JDK HttpClient的功能虽然够用但没有拦截器机制没法像OkHttp那样方便的做全局日志、全局鉴权、请求重试。不过对于那种你不愿意引入额外依赖的中间件、基础库或者开发一个简单的命令行工具JDK HttpClient是非常好的选择。它毕竟零依赖、随JDK发布维护成本最低。3. 第三方库的两个标杆Apache HttpClient与OkHttp3.1 Apache HttpClient的成熟可靠Apache HttpClient是老牌企业级HTTP客户端历史很悠久稳定性经过了大量线上验证Spring的RestTemplate底层在早期默认用的就是它现在换成了JDK HttpClient或其它。它在功能上非常全面连接池管理、路由管理、重试、Cookie管理、代理、TLS的细粒度控制几乎你能想到的它都有。用Apache HttpClient 5.x的版本做一次GET请求代码大概是这样的import org.apache.hc.client5.http.classic.methods.HttpGet; import org.apache.hc.client5.http.impl.classic.CloseableHttpClient; import org.apache.hc.client5.http.impl.classic.HttpClients; import org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager; import org.apache.hc.client5.http.config.RequestConfig; import org.apache.hc.client5.http.HttpHostConnectException; import org.apache.hc.core5.util.Timeout; var cm new PoolingHttpClientConnectionManager(); cm.setMaxTotal(200); cm.setDefaultMaxPerRoute(50); RequestConfig config RequestConfig.custom() .setConnectTimeout(Timeout.ofSeconds(5)) .setResponseTimeout(Timeout.ofSeconds(10)) .build(); try (CloseableHttpClient client HttpClients.custom() .setConnectionManager(cm) .setDefaultRequestConfig(config) .build()) { HttpGet get new HttpGet(https://api.example.com/user/123); get.setHeader(Accept, application/json); client.execute(get, response - { System.out.println(response.getCode()); System.out.println(response.getEntity()); return null; }); }Apache HttpClient最值得研究的是它的连接池管理。PoolingHttpClientConnectionManager负责维护到不同目标主机的连接复用setMaxTotal(200)表示整个连接池最多200个连接setDefaultMaxPerRoute(50)表示到同一个目标主机的最大连接数。这两个参数如果设置不合理要么连接被耗尽、要么大量连接被闲置浪费。我建议根据线上实际流量去观察监控数据调整而不是拍脑袋定一个值。还有一点Apache HttpClient 5.x的API和4.x差异非常大如果你网上搜到的大部分资料是4.x的写法下载的依赖却是5.x代码会编译不过。我自己就踩过这个坑导入的HttpClientBuilder在不同版本里的包名都不一样4.x是org.apache.http.impl.client.HttpClientBuilder5.x变成了org.apache.hc.client5.http.impl.classic.HttpClients。所以用的时候一定先确认版本再写代码。3.2 OkHttp的轻量与高效OkHttp是Square公司开源的产品也是Android和很多Java后端项目里非常流行的HTTP客户端。它的API设计走的是链式调用的路线代码写起来非常直观底层对连接池、HTTP/2、Socket的优化也做得很好。很多流行的Java生态组件比如Retrofit底层就是用它。一个典型的GET请求长这样import okhttp3.OkHttpClient; import okhttp3.Request; import okhttp3.Response; import java.util.concurrent.TimeUnit; OkHttpClient client new OkHttpClient.Builder() .connectTimeout(5, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .writeTimeout(10, TimeUnit.SECONDS) .build(); Request request new Request.Builder() .url(https://api.example.com/user/123) .header(Accept, application/json) .build(); try (Response response client.newCall(request).execute()) { if (!response.isSuccessful()) { throw new IOException(Unexpected code response); } System.out.println(response.body().string()); }这段代码里try-with-resources是关键Response内部持有Socket连接不关闭的话连接不会回到连接池长时间运行必然导致连接泄漏。这个坑我见过好几次尤其是一些刚用OkHttp的同事读完response.body().string()就以为万事大吉了实际上响应体流没有被关闭连接一直被占用。OkHttp的异步调用方式是通过enqueue回调client.newCall(request).enqueue(new Callback() { Override public void onFailure(Call call, IOException e) { // 处理失败 } Override public void onResponse(Call call, Response response) throws IOException { try (Response resp response) { // 处理响应 } } });这里有个细节onResponse回调里你用完的Response要及时关闭try-with-resources是个好习惯。另外OkHttp的拦截器机制非常强大你可以自定义一个Interceptor在请求发出前打印URL、Header、请求体在响应回来后打印耗时和状态码这在排查联调问题上特别有用。我通常在项目里做三层拦截日志拦截器、统一鉴权拦截器自动往Header里塞token、重试拦截器针对幂等GET请求做一次重试。OkHttp的线程模型也值得一提同步请求会在调用线程执行异步请求会交给自己内部的Dispatcher线程池管理这个线程池的最大并发数默认是64如果业务里有大量异步调用可以关注一下这个参数。3.3 连接池与线程安全的实践心得无论你选Apache HttpClient还是OkHttp连接池和线程安全始终是两个绕不开的话题。HTTP连接的建立是非常耗时的操作一次TCP握手加上TLS握手快的话也要几十毫秒如果每个请求都新建连接性能会大打折扣。这也是为什么我不建议用裸的HttpURLConnection去承载高并发。连接池的核心参数就那么几个最大连接数、每路由最大连接数、空闲连接存活时间、连接获取超时时间。在生产环境里我一般这样配单机QPS在1000左右的服务maxTotal配200defaultMaxPerRoute配50空闲连接存活时间设在60秒左右太短会导致频繁建连太长又会占用无谓的文件描述符。还要注意定期从连接池里踢掉已失效的连接——服务端可能因为防火墙策略主动断开空闲连接客户端如果不知道拿着“死连接”去发请求会先报一个连接重置的异常。Apache HttpClient的evictExpiredConnections和evictIdleConnections机制、OkHttp的连接池自动清理机制本质上都是在解决这个问题。线程安全方面OkHttpClient、CloseableHttpClient都是线程安全的可以全局共享一个实例不要每来一个请求就new一个client那样连接池形同虚设还会频繁创建线程和Socket对GC也不友好。如果你要在不同场景下用不同的超时时间或不同的拦截器建议用newBuilder()复制出一个新的client实例OkHttp的OkHttpClient.newBuilder()会共享连接池而不是重新new一个。4. Spring生态与工具库从RestTemplate到WebClient再到Hutool4.1 RestTemplate同步调用的经典选择如果你在用Spring BootRestTemplate大概率是你最先接触到的HTTP调用工具。它最大的优势是“约定优于配置”的API设计你不需要关心底层是用的哪个HTTP客户端实现只需要关注URL、请求头、请求体、响应体这几个核心元素。做一个POST JSON请求代码是这样的import org.springframework.http.*; import org.springframework.web.client.RestTemplate; import com.fasterxml.jackson.databind.JsonNode; RestTemplate restTemplate new RestTemplate(); HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(your-token); String body {\name\:\张三\,\age\:30}; HttpEntityString entity new HttpEntity(body, headers); ResponseEntityJsonNode response restTemplate.exchange( https://api.example.com/user, HttpMethod.POST, entity, JsonNode.class); if (response.getStatusCode().is2xxSuccessful()) { JsonNode data response.getBody(); // 处理业务数据 }不过使用RestTemplate有两点需要特别留意。第一默认的SimpleClientHttpRequestFactory底层用的是HttpURLConnection性能一般而且默认不启用连接池。我一般在项目里会用HttpComponentsClientHttpRequestFactory替换掉它让它底层走Apache HttpClient的连接池能力。配置方式可以这样HttpComponentsClientHttpRequestFactory factory new HttpComponentsClientHttpRequestFactory(); factory.setConnectTimeout(5000); factory.setReadTimeout(10000); // 如果有连接池配置通过 setHttpClient 传入 RestTemplate restTemplate new RestTemplate(factory);第二RestTemplate在Spring 5之后的官方文档中被标记为“维护模式”Spring官方推荐用WebClient替代。但现实是大量存量项目还在用RestTemplate而且对于同步调用场景RestTemplate的代码可读性和调试便利性确实非常好。我自己的建议是新项目如果是纯同步业务用RestTemplate没毛病如果项目本身是响应式技术栈直接用WebClient如果之前已经用了RestTemplate且没有明显的性能瓶颈没必要强行迁移技术债没你想的那么大。4.2 WebClient非阻塞与响应式WebClient是Spring WebFlux的一部分它基于Reactor的响应式编程模型底层默认使用Reactor Netty作为HTTP客户端也支持切换其他实现。它的核心价值在于非阻塞——一个线程可以同时处理多个请求的IO等待线程利用率更高非常适合IO密集型场景比如网关、聚合服务。一个最基本的GET请求这样写import org.springframework.web.reactive.function.client.WebClient; import reactor.core.publisher.Mono; WebClient client WebClient.builder() .baseUrl(https://api.example.com) .defaultHeader(Accept, application/json) .build(); MonoString result client.get() .uri(/user/123) .retrieve() .bodyToMono(String.class); // 阻塞等待结果仅在非响应式上下文里使用 String body result.block(Duration.ofSeconds(10));如果你在Spring WebFlux的环境里直接返回Mono由框架异步处理如果你是想在传统的Spring MVC项目里“尝鲜”WebClient可以像上面那样用block()同步等待但要注意这样其实会阻塞调用线程失去非阻塞的意义。WebClient真正的优势体现在高并发、长连接的场景下比如实时推送、网关转发、并发聚合多个上游接口。我自己在一个网关项目里用WebClient并发请求5个下游服务把耗时才从同步串行的800毫秒降到300多毫秒。但也要说实话WebClient的调试难度比RestTemplate高一些响应式链路一旦出错堆栈信息不够直观需要配合log()操作符和Reactor Debug模式去排查。另外WebClient的响应式编程模型对团队成员有学习门槛如果你所在的团队没人写过Reactor代码引入WebClient之前最好先评估一下维护成本。我个人看法是这样的单体小项目优先用RestTemplate真有高并发IO压力了再考虑WebClient别为了“新”而“新”。4.3 Hutool HttpUtil效率神器与它的边界Hutool是国产的一套Java工具类库它的HttpUtil让HTTP请求的代码量缩减到了一个极致。一个GET请求一行代码import cn.hutool.http.HttpUtil; import cn.hutool.http.HttpRequest; import cn.hutool.http.HttpResponse; String result HttpUtil.get(https://api.example.com/user/123);一个POST JSON请求也不到五行HttpResponse response HttpRequest.post(https://api.example.com/user) .header(Content-Type, application/json) .body({\name\:\张三\}) .timeout(10000) .execute(); String body response.body();Hutool的API封装得非常“懂业务”body()会自动处理响应流关闭HttpRequest链式调用直观内置的HttpUtil.get/post对于小项目、代码片段、自动化脚本来说堪称利器。但它也有明显的边界第一它默认没有连接池每次请求都会创建新的连接虽然Hutool内部有连接池的封装类但相较于OkHttp和Apache HttpClient底层能力还是薄弱一些第二不支持HTTP/2第三自定义拦截器、复杂路由这些功能它也没有。我的定位很明确Hutool适合“快速搞定一个接口调用”的场景比如单元测试里临时验证一个接口、运维脚本里调一个内部服务、或者小项目里不想引入Spring那套体系。但如果你在做一个正经的微服务项目HTTP调用是核心链路之一我不建议把Hutool作为唯一方案更推荐OkHttp或Apache HttpClient这样更扎实的底层库。5. 高频问题排查与技术细节沉淀5.1 超时配置不生效很多人在本地调试正常一上线上环境就偶发“请求卡住几分钟才报错”。排查下来多半是超时配置没生效。这里要分几层看HTTP客户端配置的超时只是第一层防护TCP层面的连接超时、服务端自己的处理超时、网关层的超时每一层都可能成为瓶颈。我见过一个案例调用方设置了10秒超时但服务端处理这个请求本身要15秒导致超时之后调用方以为失败其实服务端那边业务已经执行完了这种场景下需要的是“全局超时链路”思维从客户端到网关到服务端每一层的超时时间必须递减留给上游充足的处理余地。另外一个容易被忽略的点是OkHttp里的readTimeout并不是从请求发出开始算的而是从连接建立、开始读响应算起如果响应体特别大读取一半卡住等到的是SocketTimeoutException这个在日志里和普通的超时异常要区分开。5.2 响应乱码与编码问题乱码问题是HTTP调用里最常见的现象几乎每个人都会遇到。原因就一句话客户端和服务端的字符编码不一致。服务端返回的响应头里如果带着Content-Type: application/json; charsetutf-8那一般没问题如果服务端没返回charset客户端默认按系统编码去解Linux上通常是UTF-8Windows上可能是GBK乱码就出现了。处理方式有三种第一能改服务端就让服务端规范返回charset第二客户端在解析时指定编码比如用BodyHandlers.ofString(StandardCharsets.UTF_8)第三实在无法确定编码可以先用Tika等工具做编码探测再把字节流转成字符串。Hutool的HttpUtil.get内部默认按UTF-8解码如果你调的接口返回GBK就会乱码需要改用HttpUtil.get(url, Charset.forName(GBK))。5.3 SSL/TLS证书报错调用HTTPS接口时经常遇到PKIX path building failed这样的异常。这通常是目标服务器证书链不完整或者使用了自签名证书。正规处理方式是把目标证书导入到JDK的cacerts信任库中keytool -import -alias example -keystore $JAVA_HOME/jre/lib/security/cacerts -file example.crt我不推荐在代码里写“信任所有证书”的逻辑虽然网上搜到的大多数教程都这么教但这样等于把SSL的防护卸掉了属于饮鸩止渴。如果只是联调阶段临时用可以上线前必须改回正规方式。项目里如果对接的是内部服务、证书是自签的更好的做法是使用专门的SSLContext配置只信任你内部CA签发的证书而不是全盘信任。另外JDK 11之后默认禁用TLS 1.0/1.1如果对端服务还在用老版本TLS协议会握手失败需要排查服务端的TLS协议版本和加密套件配置。5.4 连接池耗尽与端口耗尽高并发场景下如果连接池配置不合理会出现连接池耗尽Connection pool exhausted或者本地端口不够用No buffer space available的错误。连接池耗尽的本质是“连接申请速度”大于“连接归还速度”要么并发太高、连接池上限太小要么有些连接被泄漏了响应流没关闭。解决思路第一步检查代码里响应是否正常关闭这是最常见的泄漏点第二步调整连接池参数maxTotal和defaultMaxPerRoute根据实际QPS估算一下第三步如果还是有异常检查是不是存在慢请求长时间占着连接不释放需要配合监控来看P99耗时和连接池活跃连接数。端口耗尽这个问题在Linux上偶尔出现表现为Cannot assign requested address原因大多是请求量太大、短连接太多TIME_WAIT状态的连接积压过多。解决办法是换用连接池、减少短连接、适当调整内核参数net.ipv4.tcp_tw_reuse和tcp_fin_timeout但这只是临时方案根本方案还是长连接复用。5.5 高频问题的速查清单问题现象可能原因排查方向与解决建议请求一直卡住直到超时服务端处理慢未设置读取超时逐层检查超时配置关注服务端P99耗时响应乱码服务端未返回charset双方编码不一致统一UTF-8解析时指定编码抓包看响应头PKIX证书报错证书链不完整或自签名导入信任库不要盲目信任所有证书连接池耗尽连接泄漏并发过高检查响应流关闭调大连接池用监控观测本地端口耗尽大量短连接没有复用使用连接池复用客户端实例内核参数调优高并发下偶发连接重置服务端断开了空闲连接客户端定期清理失效连接配置空闲连接校验5.6 拦截器与统一日志无论用哪种框架我都建议在HTTP客户端层加一个全局的日志拦截器。它最大的价值不是好看而是当线上出现问题的时候你能够拿出“某个请求在什么时间、调了哪个URL、请求头是什么、请求体是什么、返回什么”这样的完整链路信息。OkHttp的拦截器实现最方便public class LoggingInterceptor implements Interceptor { Override public Response intercept(Chain chain) throws IOException { Request request chain.request(); long start System.nanoTime(); Response response chain.proceed(request); long elapsed TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start); System.out.printf(%s %s %.2fms%n, request.method(), request.url(), elapsed); return response; } }要注意日志打印时要考虑敏感信息脱敏Header里的Authorization、请求体里的手机号、身份证号这些不该落到日志里否则安全审计就有风险。我在实际项目中会封装一个脱敏工具方法在输出前对请求体做一次脱敏替换。RestTemplate则可以用ClientHttpRequestInterceptor实现类似的效果。5.7 重试机制的正确姿势HTTP调用失败是常态网络抖动、服务重启、偶发超时都可能导致失败。如果业务允许重试是提升可用性最简单有效的手段。但重试不是盲目“再试一次”。首先重试只建议用在幂等请求上比如GET、PUT、DELETE这种天然或约定为幂等的操作POST请求如果服务端处理了但响应超时你重试可能导致“重复下单”或“重复扣款”这种场景必须配合全局唯一ID做幂等控制。其次重试次数建议在1~2次重试间隔用指数退避比如第一次等200ms第二次等800ms避免重试风暴把下游打爆。最后重试一定要有超时和熔断意识——下游服务已经故障了你还在疯狂重试只会让故障扩散。我在项目里会用OkHttp的拦截器做重试会根据响应码和异常类型分情况处理连接超时可以重试读超时如果请求幂等可以重试业务错误码一律不重试。6. 我的最终建议与一段保养心得如果要用一句话概括我这么多年的实践体会没有完美的HTTP客户端只有适合你项目状态的方案。JDK 11以上的轻量项目优先用JDK HttpClient省心Spring生态的项目同步场景RestTemplate异步/高并发场景WebClientJDK 8项目或者想要更细粒度控制的直接上OkHttp临时脚本和快速调试Hutool最香。这些都是经过我线上项目验证过的路线你照着我这几套组合去选型至少不会犯大方向上的错误。最后再分享一个很多人忽略的点HTTP客户端的版本升级不是小事。我见过两个案例一次是Apache HttpClient从4.x升到5.x大量代码和依赖冲突团队花了两个迭代才消化完另一次是OkHttp从3.x升到4.x因为包名从okhttp3变成了okhttp34.x也有改动还有Kotlin标准库的传递依赖问题导致上线后GC压力变大。所以在升级之前先看release notes评估变更范围、跑一遍全链路回归测试别看着有新版本就手痒直接升级。另外建议把HTTP客户端的常用配置连接池参数、超时时间、重试策略、日志级别做成配置项放到配置中心里这样线上出了问题可以在不重新发版的情况下动态调整——这个细节可以在关键时刻帮你省下宝贵的故障处理时间。