默认http.Client不设超时，Do()会无限等待；需显式设Timeout或用Transport精细控制各阶段超时；应全局复用client实例，它线程安全；请求级context通过req.WithContext()注入，不可存于client中。
为什么默认的 http.Client 会卡住或超时？
Go 的 http.Client 默认不设超时，一旦后端响应慢、网络抖动或连接卡在 TLS 握手阶段，Do() 就会无限等待。这不是 bug，是设计选择——但生产环境必须主动控制。
- 必须显式设置
Timeout，或更精细地用Transport控制各阶段超时（如DialContext、TLSHandshakeTimeout） -
Timeout是“整个请求生命周期”的上限，包括 DNS 解析、连接、写请求、读响应头、读响应体 - 如果只关心“连接建立不超时”，但允许大文件下载耗时较长，就不能只靠
Timeout，得拆解配置Transport
如何安全复用 http.Client 实例？
每个请求都 &http.Client{} 新建实例，会导致连接不复用、文件描述符暴涨、DNS 缓存失效。正确做法是全局复用一个 client，但要注意它不是线程安全的——其实它是：只要不并发修改其字段（如 Transport 或 CheckRedirect），多个 goroutine 调用 Do() 完全安全。
- 定义为包级变量或依赖注入的单例：
var httpClient = &http.Client{Timeout: 10 * time.Second} - 不要在 handler 里每次 new client；也不要为每个用户/租户创建独立 client（除非需隔离 Transport 策略）
- 若需定制 Header 或 Body，改用
http.NewRequestWithContext()构造请求，再传给复用的 client
http.Client 和 context.Context 怎么配合中断请求？
超时只是 context 的一种用法；实际中更多需要手动取消（比如用户关闭页面、前端 abort fetch）、或加入 trace ID 透传。关键点：client 本身不持有 context，而是通过 req.WithContext() 注入。
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca", nil) req.Header.Set("X-Request-ID", "abc123")
resp, err := httpClient.Do(req) if err != nil { // 可能是 context.Canceled、context.DeadlineExceeded，或 net.Error if errors.Is(err, context.Canceled) { log.Println("request canceled by user") } return } defer resp.Body.Close()
- 务必调用
cancel()，否则 context 泄露，goroutine 和 timer 不释放 -
errors.Is(err, context.Canceled)比err == context.Canceled更健壮，因为底层可能 wrap - 不要把 context 存在 client 字段里——client 是复用的，context 是 per-request 的
自定义 http.Transport 常见陷阱
多数性能和稳定性问题出在 Transport 层：连接池没调优、HTTP/2 被意外禁用、代理配置错误、忽略 TLS 验证（仅测试可用）。
立即学习“go语言免费学习笔记（深入）”；
-
MaxIdleConns和MaxIdleConnsPerHost默认都是 100，高并发下可能不够；设为 0 表示不限制（但受系统 fd 限制） - 若服务端支持 HTTP/2，默认开启；但若中间有不兼容的 proxy，可强制关掉：
ForceAttemptHTTP2: false - 跳过证书验证（仅开发）：
TLSClientConfig: &tls.Config{InsecureSkipVerify: true}—— 切记不能上生产 - 设置代理：
Proxy: http.ProxyURL(&url.URL{Scheme: "http", Host: "127.0.0.1:8888"})
真正容易被忽略的是：Transport 的 IdleConnTimeout 和 KeepAlive 影响长连接复用效率，而很多业务压测时只看 QPS，没观察 ESTABLISHED 连接数是否稳定。
