Go http.Transport ExpectContinueTimeout 导致上传请求久等怎么办

如果 Go 的大文件上传在“请求头已经发出”后迟迟没有继续，先别急着把所有超时都调大。最常见的原因是请求带了 Expect: 100-continue，客户端正在等待服务器对请求体的许可。此时应该先看 http.Transport.ExpectContinueTimeout，再区分它与已经写完请求体后等待响应头的 ResponseHeaderTimeout。

官方地址：https://pkg.go.dev/net/http#Transport

实用的处理原则是：确实需要避免无意义的大请求体时保留一个有限的非零等待；服务端不支持或不使用 100 Continue 时，可以把它设为零，让请求体立即发送；无论采用哪种策略，都给请求绑定业务上下文，避免单次上传无限等待。

先确认等待发生在请求体之前

ExpectContinueTimeout 只和带有 Expect: 100-continue 的请求有关。它描述的是：请求头写完后，Transport 等待服务器首部响应的时间。等待期间，请求体还没有正常发送。零值则表示不等待服务器批准，直接发送请求体。

下面这张结构图把几个容易混淆的边界放在一起。Request.Context 负责整个请求生命周期，而不是只负责 100 Continue 协商。

可以先用一个最小配置表达意图：

package main

import (
    "context"
    "net/http"
    "time"
)

func client() *http.Client {
    transport := http.DefaultTransport.(*http.Transport).Clone()
    // 非零值只控制 Expect: 100-continue 的等待，不是整个请求的总超时。
    transport.ExpectContinueTimeout = 2 * time.Second

    return &http.Client{Transport: transport}
}

func requestContext() (context.Context, context.CancelFunc) {
    // 用业务截止时间兜住建连、协商、上传和读响应的完整生命周期。
    return context.WithTimeout(context.Background(), 30*time.Second)
}

这里复用并克隆默认 Transport，是为了保留默认代理、连接缓存等设置；实际项目不要每次请求都新建一个 Transport。代码没有强制添加 Expect 头，是否进入这条等待路径还取决于请求头和 Transport 的实际处理。

看懂非零值和零值的差别

非零 ExpectContinueTimeout 的含义不是“服务器响应头最多只能等这么久”。它只约束请求头写出以后、请求体发送以前的 100-continue 协商。服务器如果及时发送 100 Continue，客户端就可以继续传输请求体；如果服务器没有及时给出许可，Transport 会按该配置结束等待并继续处理请求。

零值更直接：不等待服务器批准，立即发送请求体。它适合服务端明确不使用 100 Continue、请求体本身很小，或者业务更重视减少协商等待的场景。但如果请求体很大、服务端可能根据权限或大小直接拒绝，零值会让被拒绝的请求也先传输更多数据。

这不是“非零永远更安全”或“零值永远更快”的选择，而是请求体成本与服务端预检能力之间的取舍。

按服务器行为选择等待策略

排查时可以把服务器表现分成三类：

• 服务器发送 100 Continue：说明协商链路存在，检查等待值是否大到掩盖了服务端响应迟缓。
• 服务器直接返回最终状态：例如权限、大小或业务条件不满足，客户端可能不应继续发送完整请求体，应保留非零等待并记录最终状态。
• 服务器没有及时返回首部：这时要确认请求是否真的带了 Expect，再区分是协商等待还是网络、TLS、服务端处理问题。

下面的代码把请求头显式写出来，便于审查调用方是否真的开启了这条语义：

func newUploadRequest(ctx context.Context, url string, body io.Reader) (*http.Request, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodPut, url, body)
    if err != nil {
        // URL 或方法非法时，把创建阶段错误原样交给上层。
        return nil, err
    }
    // 只有服务端理解 100-continue 且请求体成本较高时才保留这个请求头。
    req.Header.Set("Expect", "100-continue")
    return req, nil
}

示例中的 io.Reader 需要在文件顶部补充 io 包。真正上线时，还要确认请求体是否可重放、服务端是否会在最终拒绝前读取请求体，以及代理是否改变了这组首部。不要因为看到“上传很慢”就把所有问题都归到 ExpectContinueTimeout。

用请求上下文兜住总耗时

无论等待策略如何设置，调用方都应该给请求绑定上下文。ExpectContinueTimeout 是 Transport 的一个局部边界，不能替代业务总截止时间；ResponseHeaderTimeout 也只针对请求体完整写出后的响应头等待。

func doUpload(client *http.Client, req *http.Request) error {
    res, err := client.Do(req)
    if err != nil {
        // 上下文取消、协商失败或建连错误都由调用方统一处理。
        return err
    }
    defer res.Body.Close() // 读完或放弃响应时释放连接资源。
    if res.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("upload rejected: %s", res.Status)
    }
    return nil
}

如果业务需要区别“总截止时间到了”和“服务端拒绝”，可以在外层用 errors.Is(err, context.DeadlineExceeded) 判断上下文错误，同时保留服务端返回的状态码和响应体摘要。不要把完整上传内容写进日志。

用决策表统一排查

结论与常见追问

Go 上传请求久等时，先定位等待点：请求体之前看 ExpectContinueTimeout，请求体之后看 ResponseHeaderTimeout，整个调用的兜底交给 Request.Context。服务端确实利用 100 Continue 时使用有限非零值；服务端不使用协商且请求体成本低时，零值通常更简单。

ExpectContinueTimeout 能限制整个上传时间吗？

不能。它只描述带有 Expect: 100-continue 的请求在发送请求体前等待服务器首部响应的时间。整个上传应使用请求上下文或更上层的业务超时。

把 ExpectContinueTimeout 设为零会关闭 HTTP keep-alive 吗？

不会。它只改变 100-continue 协商等待；连接复用由 Transport 的连接管理和响应体关闭等因素决定。

为什么调大 ResponseHeaderTimeout 仍然没有改善？

如果请求还停留在请求体发送前，ResponseHeaderTimeout 尚未成为主要边界。先确认 Expect 头、服务端是否发送 100 Continue，以及请求上下文是否提前取消。