Golang 原生 http 包如何设置请求超时时间？

先抛个结论：很多Go开发者在这件事上踩过坑，只配了http.Client.Timeout一个参数，结果线上还是卡死、goroutine泄漏。问题出在哪？简单说，Timeout只管从调用client.Do()到读完响应体的整个过程，但DNS查询、TCP连接建立、TLS握手这些前置阶段，它一概不管。换句话说，如果DNS解析卡住30秒，或者目标服务器防火墙直接丢包导致connect()挂起，Timeout完全不会生效——它连计时的起点都没到。

一个典型的现场：用netstat一看，大量连接处于SYN_SENT或ESTABLISHED状态；再跑一下pprof，好几百个goroutine卡在runtime.netpoll上。这就是只设Timeout不设下层超时的后果。

所以，只靠Timeout兜底是远远不够的，必须显式配置三层超时。这里有几个关键点需要注意：Timeout本身是个兜底值，建议≤30秒，但不能替代分层控制。如果同时设置了Transport级的超时，Timeout会覆盖它们——除非你把它设为0。另外，重定向（302）默认开启，每次跳转都重新计入Timeout，一不小心就容易误判为超时。

真正防卡死，得配齐这三个 Transport 超时字段

要主动中断各阶段系统调用，得让http.Transport把下面几个字段设好：

• DialContext：这是最容易被忽略的环节。用&net.Dialer{Timeout: 5 * time.Second}来控制DNS解析和TCP建连的耗时。不设的话，系统默认的Dialer超时是无限长的，一旦网络有波动，请求就能卡到地老天荒。
• TLSHandshakeTimeout：HTTPS场景必须显式设，比如3 * time.Second。默认值是10秒，在弱网环境下，握手失败前会白白等很久。
• ResponseHeaderTimeout：从发完请求到收到HTTP响应头的上限时间。防的是服务端“写一半就挂了”的情况，推荐设在2到5秒之间。

看一个典型配置：

client := &http.Client{
    Timeout: 10 * time.Second,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{
            Timeout:   5 * time.Second,
            KeepAlive: 30 * time.Second,
        }).DialContext,
        TLSHandshakeTimeout:   3 * time.Second,
        ResponseHeaderTimeout: 3 * time.Second,
        IdleConnTimeout:       30 * time.Second,
    },
}

单次请求，用 context.WithTimeout 才是正解

硬编码Client.Timeout不够灵活。比如查用户信息只给2秒超时，但支付回调可能要30秒。这时候用context动态控制是更合理的做法。

• 必须调用http.NewRequestWithContext(ctx, ...)，而不是先NewRequest再半路补个WithContext——前者的context能穿透到DialContext阶段，后者不行。
• 错误判断要区分context.DeadlineExceeded和网络错误。如果是context超时，立刻返回就好，别再读resp.Body。
• 如果用了自定义RoundTripper，要确保它检查req.Context().Done()。

一个常见的错误写法：client.Do(req.WithContext(ctx))。这样context不会穿透到DialContext，等于白设。

别碰 http.DefaultClient，它为陷阱而生

http.DefaultClient.Timeout = 5 * time.Second看着省事，但根本没用。它的Transport是一个私有结构，超时参数都是零值。更可怕的是，全局修改会污染所有依赖默认client的第三方库，比如日志上报、metrics上报的基础组件，一旦有人在中间件里偷偷替换Transport，这些组件的行为就会集体异常，排查成本极高。

稳定的做法是：每个业务场景声明自己的*http.Client实例，明确绑定超时配置。哪怕只是复用同一个Transport，也比共享DefaultClient安全得多。