必须用context.withtimeout而非http.client.timeout，因后者仅兜底且不响应取消；服务端需分开配置readtimeout和writetimeout，避免超时误断流式响应。
Go HTTP客户端请求超时必须用context.WithTimeout，而不是http.Client.Timeout
很多人的直觉是设个http.Client.Timeout就万事大吉，但这个字段只控制“整个请求生命周期”，不响应外部取消信号，也无法和上游context联动。一旦下游服务卡住、DNS解析慢或连接池阻塞，Timeout照样干等到底，导致goroutine泄漏。
正确做法是把context传进req.WithContext()，再用context.WithTimeout或context.WithDeadline做精细控制：
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second) defer cancel() req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil) resp, err := client.Do(req)
-
http.Client.Timeout仅作为兜底（比如忘了传context），不能替代主动上下文管理 - 若
parentCtx本身已取消（如HTTP handler的r.Context()被关闭），子请求会立即中断，无需等Timeout触发 - 注意：
cancel()必须调用，否则context泄漏，尤其在循环或高并发场景下容易OOM
HTTP服务器端读写超时要分开配置ReadTimeout和WriteTimeout
用http.Server时，只设Timeout字段没用——它已被弃用。真正起作用的是ReadTimeout和WriteTimeout，且二者行为完全不同：
-
ReadTimeout：从连接建立到读完完整request header + body的时间上限；超时直接断连，不返回任何响应 -
WriteTimeout：从收到request到写完response的总耗时；超时会中断写入，但连接可能还开着（尤其用HTTP/2时） - 如果业务里有流式响应（如sse、chunked），
WriteTimeout必须设得比单次write间隔长，否则中间就被掐断
更安全的做法是结合context手动控制handler逻辑：
立即学习“go语言免费学习笔记（深入）”；
func handler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 8*time.Second)
defer cancel()
select {
case <-ctx.Done():
http.Error(w, "timeout", http.StatusRequestTimeout)
return
default:
// 处理逻辑
}
}
数据库查询超时不能只靠sql.Open的timeout参数
sql.Open里的timeout只影响连接初始化（如TCP握手、TLS协商），对后续Query/Exec完全无效。真正在查库时卡住，得靠context透传：
- 所有
*sql.DB方法（QueryContext、ExecContext、PrepareContext）都接受context.Context - PostgreSQL驱动（
pgx）支持pgx.QueryEx带pgx.QueryExOptions，可设QueryTimeout，但它仍是基于context实现的封装 - MySQL驱动（
go-sql-driver/mysql）若用readTimeout/writeTimeoutDSN参数，只能控制网络层，无法中断正在执行的SQL语句（如死锁等待）
所以统一用ctx最可靠：
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second) defer cancel() rows, err := db.QueryContext(ctx, "SELECT * FROM users WHERE id = ?", userID)
自定义HTTP Transport超时需避开DialContext和ResponseHeaderTimeout的常见误用
很多人以为改了Transport.DialContext就能控制连接超时，其实它只管TCP建连；而ResponseHeaderTimeout控制的是“发完request后，等到response header开始的时间”，这两者之间还有TLS握手、重定向、proxy auth等环节，全都不受控。
- 真正需要覆盖全链路，得组合设置：
DialContext（连接）、TLSHandshakeTimeout（TLS）、ResponseHeaderTimeout（首字节）、ExpectContinueTimeout（100-continue） -
IdleConnTimeout和KeepAlive影响复用连接，设太短会导致频繁重建连接，增加延迟；设太长则空闲连接占内存 - 别在
DialContext里用time.Sleep模拟超时——它阻塞整个goroutine，应使用net.Dialer的Timeout字段
一个最小可用配置示例：
transport := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: 10 * time.Second,
IdleConnTimeout: 60 * time.Second,
}
Context联动不是加个参数就完事的事——超时边界在HTTP、TCP、TLS、DB、业务逻辑之间交错嵌套，漏掉任意一层，就可能让goroutine悬在半空里不动声色地吃内存。
