HTTP客户端默认不取消请求是设计选择，需显式通过context.Context传递取消信号；必须用NewRequestWithContext、禁用Client.Timeout、确保Transport组件响应同一ctx。
为什么 http.Client 默认不取消请求？
Go 的 http.Client 本身不自动响应外部中断，它只管发请求、等响应。哪怕你按 Ctrl+C 或上层逻辑已放弃，底层 TCP 连接仍可能卡在读写状态，直到超时或服务端断开。这不是 bug，是设计选择：取消必须显式声明，靠 context.Context 传递信号。
关键点在于：http.Request 必须携带带取消能力的 context.Context，且 http.Client 要用这个上下文发起请求。否则 ctx.Cancel() 对 HTTP 请求完全无效。
-
http.NewRequest不接受裸 context，得用http.NewRequestWithContext(ctx, ...) - 别用
http.Get/http.Post等快捷函数——它们内部用的是context.Background()，无法取消 - 如果用了自定义
http.Client，确保没覆盖掉Timeout字段导致 context 被忽略（见下一条）
http.Client.Timeout 和 context.WithTimeout 冲突吗？
会。如果同时设置了 http.Client.Timeout 和 context.WithTimeout，以先触发者为准，但行为不一致：Client.Timeout 是整个请求生命周期（Dial + TLS + Write + Read），而 context.WithTimeout 是从调用 Do 开始计时，且能被任意取消（不只是超时）。
更糟的是：一旦设置了 Client.Timeout > 0，http.Transport 会在内部创建一个子 context，并忽略你传入的 request context 的取消信号——这是 Go 1.19 之前的真实坑点。
- ✅ 推荐做法：把
Client.Timeout设为0，完全交给 context 控制 - ✅ 取消逻辑统一收口在 context 层，比如
ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second) - ⚠️ 注意：如果 transport 层配置了
Transport.DialContext或Transport.TLSClientConfig，它们也得接收并响应同一个 ctx，否则 DNS 解析或 TLS 握手阶段仍可能卡住
取消后连接真的关了吗？怎么验证？
取消后，Go 会尝试关闭底层 net.Conn，但不保证立即生效。常见现象是：Do 返回 context.Canceled 或 context.DeadlineExceeded 错误，但抓包看到 FIN 还没发出去，或者连接停留在 CLOSE_WAIT 状态几秒。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这是因为 Go 的 http transport 复用连接（keep-alive），取消只中断当前 request-response 流程，不强制 kill 整个连接。除非 transport 判断该连接已“损坏”（如写失败），否则它会继续尝试复用。
- 检查错误是否为
context.Canceled：必须用errors.Is(err, context.Canceled)，不能用==直接比较 - 想强制断连？设置
req.Header.Set("Connection", "close")，但这会影响性能，慎用 - 调试时可加
log.Printf("req cancelled: %v", ctx.Err())配合net/http/httputil.DumpRequestOut观察实际发出的请求头
并发请求中取消某一个，会影响其他吗？
不会。每个 http.Request 绑定独立的 context，取消其中一个，只影响对应 goroutine 中的 Do 调用。但要注意共享资源竞争：
- 如果多个请求共用同一个
http.Client，没问题；client 是线程安全的 - 如果共用同一个
context.Context（比如都从同一个parentCtx派生），那 cancel parent 就会批量取消全部——这通常是故意设计，不是 bug - 容易漏掉的是：defer cancel() 放错位置，比如在 goroutine 外部调用，导致提前取消；正确做法是在 goroutine 内部 defer，或确保 cancel 只在必要时触发
真正难缠的是超时嵌套：比如外层 context 10 秒超时，内层每个请求设 3 秒，但 transport 的 ResponseHeaderTimeout 又设了 2 秒——这时 cancel 信号可能在 header 读取阶段就返回，你却以为是业务逻辑超时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
