Java HttpRequest expectContinue 怎么减少大请求浪费：握手语义、拒绝响应与超时处理

上传几十 MB 的附件时，最浪费的情况不是服务器返回 413，而是客户端已经把整段请求体推到网络上，服务器才说“这个请求我不接”。Java 11 引入的 HttpRequest.Builder.expectContinue(true) 可以把这次判断提前：服务器先返回错误响应或 100 Continue，请求体的 BodyPublisher 再决定是否开始供数。

expectContinue(true) 适合“请求体昂贵、服务端可能较早拒绝”的场景；它不是重试开关，也不是所有代理链路都必须配合的性能加速器。

expectContinue 解决的是哪一次浪费

普通 POST 请求通常把请求头和请求体连续发出。鉴权失败、内容长度超限或路由规则拒绝往往在服务端很早就能判断，但客户端已经开始上传。对几十 MB 的文件来说，失败的成本不只是一次 HTTP 往返，还包括上行带宽、磁盘读取和 BodyPublisher 背后的编码工作。

expectContinue(true) 修改的是请求的发送语义：客户端请求服务器先确认，服务器可以直接返回错误，也可以返回 100 Continue。只有后者到达后，BodyPublisher 才会被调用。Oracle 的 API 文档把这一点写得很明确：该开关默认关闭，开启后请求发布器会等待临时响应。

旧写法和新边界：不要把它当成自动重试

这里有一个容易混淆的点：expectContinue 不负责重试，也不会替你重新创建不可重复的请求体。一次请求收到拒绝响应后，应用是否换地址、刷新令牌或重新发起请求，仍然由业务代码决定。把它当成“失败后再发一次”，会让文件流、签名字段和幂等控制变得危险。

HttpRequest、expectContinue 与 BodyPublisher 的静态关系

代码上通常从 HttpRequest.newBuilder(uri) 开始，设置请求头、超时和 expectContinue(true)，最后绑定 BodyPublishers.ofFile(path)。关键不是 API 调用顺序，而是要把“请求体可重复读取”当成单独的设计条件。

HttpRequest request = HttpRequest.newBuilder(uploadUri)
    .header("Content-Type", "application/octet-stream")
    .expectContinue(true)
    .timeout(Duration.ofSeconds(45))
    .PUT(HttpRequest.BodyPublishers.ofFile(file))
    .build();

HttpResponse response = client.send(
    request, HttpResponse.BodyHandlers.ofString());

ofFile 让请求体可以从文件重新取得，但这不等于每种自定义 Publisher 都具备同样能力。若 Publisher 绑定了一次性输入流，拒绝、超时和应用层重发都要先定义清楚，不能只凭 expectContinue 的名字推断结果。

把拒绝响应和请求超时分开判断

收到 HTTP 错误状态与等待超时是两类证据。前者说明服务端或网关已经给出判断，应该根据状态码和响应头决定是否记录原因；后者说明请求级时间边界被触发，未必能证明服务端没有收到任何字节。

建议把结果分成三层记录：请求是否建立、响应是否到达、应用是否确认业务成功。HTTP 417、413、401 等状态不能直接归为网络故障；HttpTimeoutException 也不能直接归为服务端拒绝。日志里至少保留请求标识、文件大小、是否启用 Expect、响应状态或异常类型。

try {
    HttpResponse response = client.send(
        request, HttpResponse.BodyHandlers.ofString());
    int status = response.statusCode();
    if (status >= 200 && status 

升级清单：什么时候值得打开开关

从不带 Expect 的请求迁移到带 Expect 的请求，先在客户端和网关之间做一条小流量验证。服务端必须能正确处理预期的临时响应；代理如果吞掉或错误改写这类报文，客户端可能表现为等待变长，而不是得到更快的失败。

• 先按请求体大小设门槛，不要给所有 POST 一刀切打开。
• 为拒绝响应保留状态码和服务端请求标识，避免只看到“上传失败”。
• 确认 BodyPublisher 能够延迟读取，且业务重发有幂等键。
• 分别压测成功、提前拒绝和握手超时三条路径。

如果网关、服务端和客户端都支持得稳定，大文件上传、批量导入和可能因权限提前失败的接口通常能从中受益。小请求则更适合保持默认关闭，减少一次额外等待和兼容判断。

常见问题：Java HttpRequest 的 Expect 边界

expectContinue(true) 会自动发送 100 Continue 吗？

不会。它是向服务器请求先确认，服务器可能返回 100 Continue，也可能直接返回错误；客户端不能把 100 当作业务成功。

收到 413 后还需要重试吗？

先看接口是否支持分片或压缩。直接重发同一个大请求通常仍会被拒绝，只有改变请求边界后才有意义。

HttpRequest.timeout 能限制文件读取时间吗？

它定义请求级超时边界，但文件读取、网络拥塞和服务端处理仍需结合客户端实现与服务端指标核对。

自定义 BodyPublisher 最容易漏掉什么？

最容易漏掉可重复读取和取消处理。先确认握手拒绝、超时中断、连接复用三种情况下资源都会释放。

最后核对一次请求策略

把 expectContinue 看作“大请求发送前的协商门”，而不是一个神奇的加速按钮。请求体越昂贵、提前拒绝越常见，它的收益越明显；代理链越复杂、请求越小，越应该先用真实链路验证。最终验收以响应状态、业务标识和资源释放三项同时成立为准。