go http客户端默认无超时，须显式设置timeout、responseheadertimeout等参数，并用context控制端到端超时，错误处理需区分context.deadlineexceeded与net.error。
Go HTTP客户端默认不超时，必须手动设置
Go 的 http.Client 默认没有超时限制，一旦后端卡住或网络中断，请求会无限等待，拖垮整个服务。这不是 bug，是设计选择——让你自己决定超时策略。
常见错误现象：http.Get("https://slow-api.com") 卡住几十秒甚至几分钟，goroutine 积压，CPU 和连接数飙升。
- 必须显式配置
Timeout、Transport中的IdleConnTimeout和ResponseHeaderTimeout -
Timeout是总耗时上限（从发起到收到完整响应），覆盖 DNS 解析、连接、TLS 握手、发送请求、读响应头+体 - 如果只设
Timeout，但后端返回了 header 就挂起（比如流式接口没关连接），仍可能卡住——这时需要ResponseHeaderTimeout - 示例：
client := &http.Client{<br> Timeout: 10 * time.Second,<br> Transport: &http.Transport{<br> ResponseHeaderTimeout: 5 * time.Second,<br> IdleConnTimeout: 30 * time.Second,<br> },<br>}
Context.WithTimeout 是更灵活的超时控制方式
当超时逻辑需和业务流程联动（比如一个请求要等多个下游，整体不能超 800ms），用 context.Context 比单纯设 http.Client.Timeout 更精准。
使用场景：微服务调用链中做端到端超时传递、重试前动态计算剩余时间、与数据库查询共用同一 context。
立即学习“go语言免费学习笔记（深入）”；
-
http.NewRequestWithContext才会把 context 传给底层 transport；直接用http.Get或client.Get会忽略 context - context 超时后，连接会被主动关闭，但注意：transport 可能已复用连接，下次请求仍可能复用“半关闭”状态的连接（需配
ForceAttemptHTTP2或升级 Go 版本） - 示例：
ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)<br>defer cancel()<br>req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil)<br>resp, err := client.Do(req)
超时错误类型判断要区分 net.Error 和 context.DeadlineExceeded
错误处理时不能只看 err != nil，否则会把连接拒绝、DNS 失败、TLS 证书错误都当成“超时”，导致误判重试或降级策略。
常见错误现象：下游返回 503，但你代码里发现 err != nil 就重试，结果雪崩。
- 检查是否为超时，优先用
errors.Is(err, context.DeadlineExceeded)（推荐）或errors.Is(err, context.Canceled) - 如果是
net.Error类型，再用.Timeout()方法判断是否真超时：netErr, ok := err.(net.Error); ok && netErr.Timeout() - 注意：
context.DeadlineExceeded是一个具体的 error 值，不是类型，所以不能用errors.As断言
长轮询/流式响应需单独控制读超时，不能只靠总 Timeout
像 SSE（Server-Sent Events）、gRPC-Web 流、或分块传输的大文件下载，响应头很快返回，但 body 持续写入。此时 Timeout 会把整个流掐断，而你真正想控的是“两次数据间隔”。
性能影响：如果用短 Timeout 强制中断流，频繁重连反而增加延迟和服务器压力。
- 应禁用
Client.Timeout，改用Transport.ReadTimeout（Go 1.19+）或自定义Read超时逻辑 - Go 1.19 前只能包装
Response.Body，用time.AfterFunc+io.LimitReader或第三方库如golang.org/x/net/context配合io.ReadCloser实现 - 示例（Go 1.19+）：
transport := &http.Transport{<br> ReadTimeout: 30 * time.Second,<br>}
超时不是设个数字就完事——它得和你的业务语义对齐，也得和 transport 层的状态管理匹配。很多人漏掉 ResponseHeaderTimeout 或混淆 context.DeadlineExceeded 和普通网络错误，上线后才在压测里暴露。
