context 能控制 HTTP 请求生命周期是因为 http.Client 通过 net.Conn 的可取消读写机制，在连接建立、TLS 握手、请求发送、响应读取等各阶段监听 context.Done()，一旦触发即关闭连接并返回对应错误；必须用 http.NewRequestWithContext() 构造请求并配合 client.Do() 使用，快捷方法如 client.Get 会忽略传入 context。
为什么 context 能控制 HTTP 请求生命周期
Go 的 http.Client 原生支持 context.Context，不是靠轮询或手动中断，而是通过底层 net.Conn 的可取消读写实现的。当你传入带超时或取消信号的 context，http.Transport 会在连接建立、TLS 握手、请求发送、响应读取等任一阶段监听该 context 的 Done() 通道 —— 一旦关闭，立即触发底层连接的 Close() 并返回 context.Canceled 或 context.DeadlineExceeded 错误。
关键点：必须把 context 传给 http.NewRequestWithContext()，而不是用 http.NewRequest() 再手动塞进 req.Context = ctx —— 后者不会生效，因为 http.Client 只信任由 WithContext 构造的请求。
http.NewRequestWithContext 必须配合 client.Do 使用
常见错误是构造了带 context 的请求，但调用的是 client.Get / client.Post 等快捷方法 —— 它们内部会新建一个默认 context（不带超时），完全忽略你传的 ctx。
- ✅ 正确：用
http.NewRequestWithContext(ctx, ...)+client.Do(req) - ❌ 错误：调用
client.Get("https://...")即使你外面包了ctx，也无效 - ⚠️ 注意：
client.Timeout字段和context是两套机制，同时设置时以先触发者为准；但推荐只用context，更精细（比如可中途取消）
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
req, err := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/data", nil)
if err != nil {
log.Fatal(err)
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Println("request timed out")
} else if errors.Is(err, context.Canceled) {
log.Println("request was canceled")
}
return
}
defer resp.Body.Close()
跨 goroutine 传递 context 时别漏掉 deadline 继承
如果你在 handler 中启动子 goroutine 发起下游 HTTP 请求，直接把 handler 的 ctx 传过去通常没问题；但若中间做了 context.WithValue 或 context.WithCancel，而没显式保留原 Deadline，就可能丢失超时约束。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout(parentCtx, d)或context.WithDeadline(parentCtx, t)显式继承时间约束 - 避免仅用
context.WithCancel(parentCtx)，它不带任何时间信息，子请求可能无限 hang - 调试技巧：打印
ctx.Deadline()和ctx.Err()可快速确认是否被正确传播
注意 http.Transport 的底层连接复用与 context 取消的关系
context 取消会关闭当前连接，但不会强制终止连接池中的其他空闲连接。如果请求因 context 取消失败，而 transport 恰好刚把连接放回 idle pool，下一次请求仍可能复用它 —— 这本身不是 bug，但可能让你误以为“取消没生效”。
- 真正影响复用的是连接是否已进入读/写状态；取消正在读 body 的请求，会关闭连接并从 pool 中移除
- 如需更激进清理，可设置
Transport.IdleConnTimeout或临时禁用复用：req.Header.Set("Connection", "close") - 高并发场景下，建议统一配置
http.Transport的MaxIdleConns和MaxIdleConnsPerHost，避免因连接堆积掩盖 context 行为
最易被忽略的一点：resp.Body 必须被读完或关闭，否则连接无法释放回池，后续请求可能因连接耗尽卡住 —— 这和 context 无关，但常和超时逻辑一起出问题。
