Golang如何处理HTTP请求超时_Golang HTTP超时控制方法

HTTP客户端超时必须显式设置，Go默认不设限；需用Client.Timeout总控或Transport分阶段配置；服务端需协同Read/Write/Idle三超时；错误判断须用errors.Is或net.Error.Timeout()。

HTTP客户端超时必须显式设置，Go默认不设限

Go 的 http.DefaultClient 和零值 http.Client{} 都**没有默认超时**，一旦后端卡住或网络中断，请求可能无限期挂起。这不是 bug，是设计选择——但生产环境必须覆盖它。

最直接的方式是配置 http.Client 的 Timeout 字段，它控制整个请求生命周期（DNS + 连接 + 写请求 + 读响应）：

client := &http.Client{
    Timeout: 10 * time.Second,
}

注意：Timeout 是“总超时”，无法单独控制连接或读写阶段；若需更细粒度，得用 Transport 配置。

用 Transport 分阶段控制超时（连接、读、写）

当需要区分连接慢、响应慢、上传慢等场景时，http.Transport 的字段更合适。常见组合如下：

• DialContext：配合 net.Dialer.Timeout 控制建立 TCP 连接的上限
• TLSHandshakeTimeout：仅对 HTTPS 生效，限制 TLS 握手耗时
• ResponseHeaderTimeout：从连接建立完成到收到响应头的等待时间（不含响应体传输）
• ExpectContinueTimeout：仅用于带 Expect: 100-continue 的请求
• IdleConnTimeout 和 KeepAlive：影响连接复用，不直接参与单次请求超时

示例（连接最多 3 秒，收到 header 最多 5 秒，整个请求最多 12 秒）：

transport := &http.Transport{
    DialContext: (&net.Dialer{
        Timeout:   3 * time.Second,
        KeepAlive: 30 * time.Second,
    }).DialContext,
    TLSHandshakeTimeout:   3 * time.Second,
    ResponseHeaderTimeout
: 5 * time.Second,
}
client := &http.Client{
    Transport: transport,
    Timeout:   12 * time.Second, // 总兜底
}

HTTP Server 端超时靠 Read/Write/Idle 超时协同

服务端超时不是靠 http.Server 的单一字段，而是三个独立配置共同作用：

• ReadTimeout：从连接建立到读完 request header + body 的总时间（含 slowloris 攻击防护）
• WriteTimeout：从 request 全部读完，到 response 全部写完的时间（含 handler 执行 + write body）
• IdleTimeout：HTTP/1.1 keep-alive 或 HTTP/2 连接空闲时长，超时即断开

三者必须都设，否则留有隐患。例如只设 ReadTimeout，但 handler 卡死在 DB 查询，WriteTimeout 不生效就无意义：

server := &http.Server{
    Addr:         ":8080",
    Handler:      mux,
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout:  30 * time.Second,
}

注意：ReadTimeout 和 WriteTimeout 在 Go 1.8+ 才可用；旧版本只能靠 SetDeadline 手动控制，不推荐。

超时错误判断不能只看 error == nil

超时返回的 error 类型是 *url.Error，其 Err 字段才是关键。常见误判写法：

// ❌ 错误：超时错误不等于 net.ErrTimeout
if err == context.DeadlineExceeded { ... } // 可能为 nil
// ✅ 正确：用 errors.Is 判断上下文取消或超时
if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
log.Println("request timed out or canceled")
}
// ✅ 或检查底层 net.Error 的 Timeout() 方法
if urlErr, ok := err.(*url.Error); ok {
if netErr, ok := urlErr.Err.(net.Error); ok && netErr.Timeout() {
log.Println("network timeout")
}
}

特别注意：如果用了自定义 context.WithTimeout 包裹请求，超时 error 会是 context.DeadlineExceeded；而 http.Client.Timeout 触发的超时，底层仍是 net.Error，类型不同但语义一致。

超时控制真正难的不是设参数，而是厘清「谁在什么时候因什么而超时」——客户端总超时、Transport 分阶段、Server 各阶段 timeout、以及 context 与 client timeout 的嵌套关系，稍不留意就会漏掉一环。