超时取消必须在 handler 入口用 context.withtimeout 包装 r.context()，并透传至下游 http client、db 等；链路追踪需从请求头（如 traceparent）提取并注入 context，且每跳都须主动传递，缺一不可。
Context 超时取消必须在 handler 入口就设置
Go 的 http.ServeHTTP 不会自动传播或响应 context.Context 取消，你得自己在每个 handler 开头用 context.WithTimeout 或 context.WithDeadline 包一层。漏掉这步，下游调用（比如 HTTP client、DB 查询）就算用了 ctx 也收不到取消信号。
常见错误现象：net/http: request canceled (Client.Timeout exceeded while awaiting headers) 看似是 client 超时，实际是 handler 没传超时 context 给 http.Client，导致 client 一直等，最后被外部强制 kill。
- 永远从
r.Context()派生子 context，别直接用context.Background() - 超时时间建议设为比反向代理（如 Nginx）或前端 timeout 小 200–500ms，避免“幽灵请求”——客户端已放弃但服务端还在跑
- 如果 handler 内部要并发调用多个后端，用
context.WithCancel+errgroup.Group更稳妥，单个失败可提前 cancel 其他协程
链路追踪 ID 必须从请求头注入并透传
OpenTracing / OpenTelemetry 都依赖一个 trace ID 在整个请求生命周期里不变且跨服务传递。Golang Web 中它不会自动出现，你得手动从 r.Header.Get("X-Request-ID") 或 r.Header.Get("traceparent") 读取，并塞进新 context 里。
常见错误现象：日志里看到一堆 trace_id=00000000000000000000000000000000，或者不同服务日志无法串联——根本原因是中间某层没把 header 解析后写回 context，下游 ctx.Value() 取不到。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用中间件统一处理：
ctx = context.WithValue(r.Context(), "trace_id", traceID)，但注意context.WithValue只适合传不可变元数据，别塞结构体或指针 - 更规范的做法是用
otel.GetTextMapPropagator().Extract()（OpenTelemetry）解析traceparent，再用otel.GetTextMapPropagator().Inject()往 outbound 请求头写回 - 别依赖
log.Printf打印 trace ID，要用结构化日志库（如zerolog）绑定ctx，否则并发下容易串日志
HTTP client 调用必须显式传入 context
http.Client.Do 接收的 *http.Request 必须是用 req.WithContext(ctx) 包装过的，否则即使你 upstream handler 设置了 timeout，这个 outbound 请求也不会受控。
性能影响：不传 context 的后果不是“慢”，而是“不可控”——可能卡死 goroutine、耗尽连接池、拖垮整个实例。
- 永远不要写
client.Do(req)，必须写client.Do(req.WithContext(ctx)) - 自定义
http.Client时，Timeout字段和 context 超时是两回事：前者只控制单次 dial+read，后者控制整个调用生命周期（含重试、中间件逻辑） - 如果用了
retryablehttp这类封装库，确认它支持 context 透传；很多老版本默认忽略ctx，需手动 patch 或换github.com/hashicorp/go-retryablehttpv0.7+
数据库查询取消依赖 driver 是否实现 Context 接口
不是所有 Go DB driver 都真正支持 context.Context 取消。比如旧版 github.com/lib/pq 对 QueryContext 的实现只是检查 ctx 是否已 cancel，但不会中断正在执行的 SQL；而 github.com/jackc/pgconn（pgx v4+）能发 cancel 请求给 PostgreSQL 服务端。
容易踩的坑：本地测试时加 time.Sleep 模拟慢查询，看起来 cancel 生效了，但上线后发现 pg 死锁或 long query 依然卡住——因为 driver 没触发真正的 cancel 协议。
- PostgreSQL 推荐用
pgx/v5，MySQL 用go-sql-driver/mysqlv1.7+（支持context和timeout参数） - 检查 driver 文档是否明确写了 “supports QueryContext/ExecContext with cancellation”
- 对不支持的 driver，只能靠语句级 timeout（如 MySQL 的
SET SESSION max_execution_time = 3000），但这属于 SQL 层控制，和 Go 的 context 生命周期不联动
链路追踪和超时取消不是加几行代码就能生效的事，关键在于每一跳都得主动接住 context 并向下传——少一环，整条链就断了。
