Go中http.Client.Do响应context取消需用http.NewRequestWithContext构造请求，Transport会监听ctx.Done()并中断连接、返回context.Canceled等错误；手动赋值req.Context无效。
Go 中 http.Client 的 Do 方法如何响应 context.Context 取消？
它本身不直接监听 ctx.Done()，但只要把 context.Context 传给 http.NewRequestWithContext 构造的请求，底层 Transport 就会在 ctx.Done() 触发时主动中断连接、关闭读写并返回 net/http: request canceled 或 context deadline exceeded 错误。
关键点在于：必须用 http.NewRequestWithContext，而不是 http.NewRequest + 手动赋值 req.Context = ctx —— 后者不会被 Transport 识别，取消完全无效。
-
http.NewRequest创建的请求，其Context是background，不可取消 -
http.NewRequestWithContext(ctx, ...)创建的请求，Transport 会持续检查ctx.Done()并清理资源 - 即使请求已发出、后端正在处理，Transport 也会在收到取消信号后立即关闭底层 TCP 连接（发送 RST）
并发请求中多个 http.Request 共享同一个 context.Context 会怎样？
所有请求都会在该 context 被 cancel 或超时时同步终止 —— 这是预期行为，也是实现“批量取消”的最简方式。但要注意：共享 context 不代表请求之间有依赖，只是共用一个取消开关。
常见误用是用 context.WithCancel(context.Background()) 创建父 context，然后在 goroutine 中调用 cancel()，却忘了加锁或未确保只调一次；更隐蔽的问题是：父 context 被 cancel 后，子 goroutine 仍可能在执行 defer 或日志打印，导致 panic（如访问已关闭的 channel）。
立即学习“go语言免费学习笔记（深入）”；
- 取消操作应由单一控制点触发（例如主逻辑判断超时/用户中断）
- 每个 goroutine 内需检查
err != nil && errors.Is(err, context.Canceled)或errors.Is(err, context.DeadlineExceeded)，避免把取消误当业务错误处理 - 不要在 defer 中依赖 context 状态，因为 cancel 可能发生在 defer 执行前
为什么用 context.WithTimeout 比手动启 timer + cancel() 更可靠？
因为 context.WithTimeout 返回的 context 自带定时器和原子状态管理，cancel 函数幂等，且与 goroutine 生命周期解耦；而手写 timer 容易漏掉 stop、重复 cancel、或在 goroutine 已退出后还试图调用 cancel。
尤其在并发场景下，多个请求共享一个 timeout context 时，WithTimeout 能保证所有请求统一受控，且无需维护额外 channel 或 mutex。
-
ctx, cancel := context.WithTimeout(parent, 5*time.Second)是标准做法，cancel() 可安全多次调用 - 手动 timer 需要
defer timer.Stop()，且必须确保 timer 在 goroutine 退出前 stop，否则引发 goroutine 泄漏 - 若请求提前完成，
cancel()会提前释放 timer 资源；手动 timer 却可能仍在运行直到超时
实际并发请求中，哪些地方最容易忽略 context 传递？
不是 http.Do 这一层，而是中间链路：比如用了封装过的 client（如自定义 DoJSON 方法），但没把 context 透传进 http.NewRequestWithContext；或者在重试逻辑里每次 new Request 都用了原始 context，却忘了重试时应基于新 context（例如用 context.WithDeadline 重新计算剩余时间）。
另一个高频盲区是日志或 metric 上报 —— 在请求取消后，goroutine 仍尝试向 prometheus push gateway 发送指标，或往 zap logger 写入 trace，结果因 context 超时导致 HTTP client 自身阻塞，形成级联延迟。
- 所有网络 I/O（包括重试、fallback 请求、健康检查）都必须使用
req.Context构造新 request - 非阻塞操作（如记录日志、更新 map）建议用
select { case 避免卡住 - 第三方库（如
redis-go,mongo-go-driver）也支持 context，别只在 http 层做取消
ctx, cancel := context.WithTimeout，而是确保整个调用链——从入口 handler 到下游 SDK、中间件、重试逻辑、监控埋点——每一处 I/O 都在同一个 context 树下呼吸。漏掉任意一环，取消就变成“看起来有效，其实还在后台跑”。 
