http.Request.WithContext不够用，因为Go的http.Client默认忽略请求上下文，必须配合显式配置的client（不设Timeout）和Do调用才能生效；否则超时逻辑无法触达DNS解析、TLS握手等底层阶段。
直接用 context.WithTimeout 包裹 HTTP 请求，但必须传给 http.Client 的 Context 字段，否则超时完全不生效。
为什么 http.Request.WithContext 不够用？
很多人以为调用 req.WithContext(ctx) 就完事了，其实这只是给请求对象附上上下文，真正决定超时行为的是 http.Client 内部如何消费这个上下文。Go 标准库的 http.Client 只在发起连接、读响应头、读响应体等阶段检查上下文是否超时——前提是客户端本身被显式配置了上下文感知能力。
-
http.Client默认使用context.Background()，忽略你塞进req的上下文 - 必须把带超时的
ctx传给client.Do(req.WithContext(ctx))，且client不能是零值（需确保未禁用上下文支持） - Go 1.19+ 默认启用上下文支持；但若手动设置了
client.Timeout，它会覆盖上下文超时逻辑，优先级更低
正确写法：Client + WithTimeout + Do 三者联动
关键不是“加个 context”，而是让整个调用链路都参与进来：从创建上下文，到构造 client（不设 Timeout），再到用 Do 发起带上下文的请求。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要设置
client.Timeout，否则context.WithTimeout会被绕过 - 用
context.WithTimeout(context.Background(), 5*time.Second)创建 ctx，注意第二个参数是time.Duration，不是秒数整型 - 调用
client.Do(req.WithContext(ctx))，而不是http.DefaultClient.Do(...)—— 后者可能复用旧 client 配置 - 务必检查返回 err 是否为
context.DeadlineExceeded，这是超时的唯一可靠标识
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
req, _ := http.NewRequest("GET", "https://httpbin.org/delay/5", nil)
resp, err := http.DefaultClient.Do(req.WithContext(ctx))
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Println("request timed out")
}
}
常见超时失效场景和排查点
超时没触发？大概率卡在底层系统调用或配置冲突上。
立即学习“go语言免费学习笔记（深入）”；
- Linux 上 DNS 解析慢（如 /etc/resolv.conf 配置了不可达 DNS）会导致
net.Dial卡住，此时context.WithTimeout无法中断，需配合net.Dialer.Timeout和KeepAlive - 设置了
client.Transport但没把ctx透传下去，比如自定义RoundTripper忘了调用base.RoundTrip(req.WithContext(ctx)) - HTTP/2 连接复用时，如果底层 TCP 连接已建立但服务端迟迟不发响应，超时仍有效；但若卡在 TLS 握手阶段，某些 Go 版本存在延迟响应问题
- 测试时用
httpbin.org/delay/N要注意 N > timeout 才能触发，且避免本地代理干扰
最易被忽略的是：超时时间从 client.Do 调用开始计时，不是从服务端接收第一个字节开始。DNS、TLS、TCP 建连全算在内——这些环节出问题时，光靠 WithTimeout 不够，得配 Dialer。
