必须在 handler 入口调用 context.withtimeout，因为 dns 解析、连接建立等关键耗时操作发生在 http.servehttp 内部，若延迟创建则无法控制；需用 r.withcontext() 传递，并确保下游组件（db、http client、sdk）均主动响应 ctx.err()。
为什么 context.WithTimeout 必须在 handler 入口就调用
Go 的 HTTP handler 是并发执行的，每个请求独占一个 goroutine，但 context.Context 本身不绑定 goroutine 生命周期。如果你在中间件或业务逻辑里才创建带超时的子 context，很可能已经错过关键控制点——比如 DNS 解析、连接建立、TLS 握手这些耗时操作，都发生在 http.ServeHTTP 内部，且不受你后续创建的 context 影响。
- 必须在
http.HandlerFunc第一行就用ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second) - 别依赖
r.Context()原生值做超时判断——它默认是background，没有 deadline - 记得
defer cancel()，否则可能泄漏 timer 和 goroutine
http.Client 调用外部 API 时怎么传 context
http.Client 的 Do 方法会读取 request 的 Context()，但前提是这个 request 是用 req.WithContext(ctx) 显式挂载过的。直接复用原始 *http.Request 对象，它的 context 还是 handler 入口那个，不会自动继承你新建的带 timeout 的子 context。
- 每次外发请求前都要重新包装：
req = req.WithContext(ctx) - 别省略这步——漏了就等于这次调用完全不响应上游超时信号
- 如果用了
resty或gqlgen等封装库，确认它们是否透传 context；很多老版本默认忽略，得手动设.SetContext(ctx)
中间件里传递 context 到下一层 handler 的正确姿势
Go 的标准 http.Handler 接口不接受额外参数，所以你不能靠函数签名“传入” context。唯一可靠方式是把新 context 注入到 request 中，并确保下游代码从 r.Context() 读取——而不是自己 new 一个或沿用旧的。
- 中间件里用
r = r.WithContext(newCtx)替换 request，再调用next.ServeHTTP(w, r) - 千万别写
next.ServeHTTP(w, r)后再改 context——request 已经被消费，修改无效 - 如果下游 handler 用的是
chi或gorilla/mux，它们的RequestCtx也是基于同个机制，无需额外适配
常见超时失效场景和 debug 方法
最常遇到的现象是：设置了 3 秒超时，但请求卡住 30 秒才返回，或者 ctx.Done() 永远不 closed。问题往往不在 context 创建本身，而在阻塞点没受控。
立即学习“go语言免费学习笔记（深入）”；
- 数据库驱动（如
pgx）必须显式传ctx给Query/Exec，否则 ignore timeout - 第三方 SDK（如 AWS Go SDK）多数支持 context，但方法名常带
WithContext后缀，别误用无 context 版本 - debug 时加一句
log.Printf("deadline: %+v", ctx.Deadline())，确认是否真设置了，以及时间是否合理（注意时区/单位）
超时不是开关，是协作契约。所有参与方——HTTP server、client、DB driver、SDK——都得主动检查 ctx.Err() 并及时退出，缺一不可。
