Context.WithTimeout未使HTTP请求提前退出的根本原因是未将context传给真正执行I/O的地方，必须用http.NewRequestWithContext显式构造请求，否则超时信号无法到达底层连接。
Context.WithTimeout 为什么没让 HTTP 请求提前退出
根本原因不是 context.WithTimeout 失效，而是你没把它传给真正执行 I/O 的地方。HTTP 客户端默认不读取 context，必须显式用 http.NewRequestWithContext 构造请求，否则超时信号根本到不了底层连接。
常见错误现象：context.DeadlineExceeded 没触发，goroutine 卡在 resp, err := client.Do(req) 上几十秒；或者超时后 err 是 net/http: request canceled 而不是预期的 context error。
- 用
http.NewRequestWithContext(ctx, ...)替代http.NewRequest(...) - 确保
*http.Client没设置过长的Timeout字段（它会覆盖 context） - 如果用了自定义
Transport，检查IdleConnTimeout和ResponseHeaderTimeout是否过长，它们可能拖住 cancel 后的清理
子 goroutine 中如何正确继承并传播 cancel 信号
直接把父 context 传进去不够——如果子任务自己又起了 goroutine 或调用了第三方库，而那些代码没检查 ctx.Done()，cancel 就断在半路了。关键是要让每个可能阻塞的操作都响应同一个 ctx。
使用场景：微服务中一个 RPC 请求触发多个下游调用（DB + Redis + 另一个 HTTP），任一环节超时都要整体退出。
立即学习“go语言免费学习笔记（深入）”；
- 所有子任务启动时，用
ctx（不是context.Background()）构造新 context，例如childCtx, cancel := context.WithCancel(ctx) - 在 goroutine 结束前务必调用
cancel()，避免 goroutine 泄漏；建议用defer cancel() - 对数据库操作，优先用支持 context 的方法，如
db.QueryRowContext(ctx, ...)，而非db.QueryRow(...)
WithCancel 和 WithTimeout 混用时谁先生效
context.WithCancel 和 context.WithTimeout 返回的都是可取消 context，它们的取消逻辑是“或”关系：任一条件满足即触发 ctx.Done()。但要注意嵌套顺序影响的是 cancel 函数的控制权，不是生效优先级。
参数差异：WithTimeout(parent, d) 底层就是 WithDeadline(parent, time.Now().Add(d))；WithCancel(parent) 则完全依赖手动调用 cancel()。
- 不要写
ctx, _ := context.WithCancel(context.WithTimeout(parent, 5*time.Second))—— 外层 cancel 会屏蔽内层 timeout - 想同时支持手动 cancel 和自动超时，用
context.WithTimeout创建，需要时再调cancel() - 注意：多次调用同一个
cancel()函数是安全的，但不会报错也不会重复触发
HTTP Server 端怎么利用 Context 做请求级超时
很多人只记得客户端加 context，忘了 server 端的 http.Request.Context() 其实已经绑定了请求生命周期。这个 context 在客户端断开、超时或服务端 WriteTimeout 触发时会自动 cancel，但你需要主动监听它。
性能影响：不监听 ctx.Done() 可能导致长耗时处理（比如大文件生成、复杂计算）继续跑完，浪费资源；监听但没做 cleanup（比如关 DB 连接、停 goroutine）也会泄漏。
- 在 handler 开头就检查
if err := ctx.Err(); err != nil { return } - 对长时间运行的循环，每轮加
select { case - 避免在 handler 里用
context.Background()启动新 goroutine；要用req.Context()衍生
容易被忽略的一点：标准 http.Server 的 ReadTimeout 和 WriteTimeout 是连接级的，和 request context 无关；真正由 context 控制的是单个请求的处理时长，两者要配合着设，不然会出现“连接已断但 goroutine 还在跑”的情况。
