单靠pprof无法直接测context传递耗时，但可通过cpu profile识别其副作用：若context.withvalue或(*valuectx).value高频出现，说明key滥用或嵌套过深；若runtime.selectgo/routine.gopark激增，则可能ctx.done()阻塞导致调度开销大。
怎么用 pprof 看 context 传递是否拖慢链路
context 本身几乎不耗 CPU，但错误的传递方式会让链路变慢——比如在 hot path 上反复 WithValue、或在循环里无脑 WithTimeout 派生。真正要测的不是 context，而是它引发的副作用。
用 go tool pprof 抓 CPU profile 时，重点看这些函数调用栈：
-
context.WithValue出现在高频路径（如每请求都调一次）→ 说明 key 冲突或滥用 -
context.(*valueCtx).Value占比异常高 → 可能 key 类型没做对，导致线性遍历 -
runtime.selectgo或runtime.gopark被大量触发 → 很可能是ctx.Done()channel 频繁阻塞，背后是取消信号扇出失控
示例：如果 ctx.Value(traceKey{}) 在日志中间件里被调用 10 万次/秒，而 key 是 type traceKey struct{}，那没问题；但若 key 是 "trace_id" 字符串，实际会触发 valueCtx.find 的链表遍历，性能直接掉一个数量级。
为什么 WithValue 多层嵌套会让 trace 关联变慢
WithValue 不是哈希表，而是链表式嵌套：每次调用都新建一个 valueCtx，Value() 查找时从当前 ctx 开始逐层向上匹配 key 地址。层数越多，查找越慢，且无法内联优化。
常见陷阱：
- 中间件 A 做
ctx = context.WithValue(ctx, k1, v1)，中间件 B 又做ctx = context.WithValue(ctx, k2, v2)，下游取k2时得跳过k1节点 - HTTP handler 里循环调用 DB 查询，每次都在循环内
context.WithValue(ctx, reqIDKey, fmt.Sprintf("req-%d", i))→ 每次都新增一层，第 100 次调用时Value()要遍历 100 层 - key 类型用了导出结构体（如
type TraceKey struct{}），不同包定义同名类型 → 实际是不同 key，查不到值，白跑一遍链表
解决办法只有一个：WithValue 只在入口层做一次，后续全靠函数参数透传业务字段；元数据 key 必须用未导出空 struct，全局唯一变量（如 var traceKey = struct{}{}）。
ctx.Done() 频繁 select 导致 goroutine 切换开销大
很多人以为 select { case 是零成本监听，其实不然。每次 select 都涉及 runtime 的 channel 状态检查和 goroutine park/unpark。当这个 select 出现在 tight loop 里（比如轮询状态、流式处理），性能损耗会指数级放大。
典型场景：
- 长连接心跳协程里，每 10ms 就
select { case → 实际变成 busy-wait + 高频调度 - RPC 客户端封装层，在每次写入前都加
select { case ，但底层 transport 已经在用同一个 ctx 监听 → 重复检查 - 用
time.AfterFunc配合ctx.Done()做超时兜底，却忘了AfterFunc自身也启动 goroutine → 额外调度负担
更轻量的做法：只在关键阻塞点（如 http.Do、db.QueryContext、chan send/receive）使用 ctx，非阻塞逻辑直接判断 ctx.Err() != nil，避免 select 开销。
跨服务调用时 context 超时没生效，其实是 HTTP header 没传对
context.WithTimeout 只影响当前进程内的 goroutine，不会自动变成 X-Request-Timeout 发出去。下游收不到超时信号，就会继续执行，造成“上游已返回，下游还在忙”的假性卡顿。
必须手动透传：
- 上游发起 HTTP 请求前，显式设置 header：
req.Header.Set("X-Request-Timeout", strconv.FormatInt(int64(timeoutMs), 10)) - 下游 HTTP handler 中，解析该 header 并派生新 ctx：
timeoutMs, _ := strconv.ParseInt(r.Header.Get("X-Request-Timeout"), 10, 64); ctx, cancel := context.WithTimeout(r.Context(), time.Duration(timeoutMs)*time.Millisecond) - 别依赖
X-Request-ID传 timeout —— 它只是 trace 辅助字段，语义上不承诺携带超时信息
最容易被忽略的一点：很多 SDK（如 OpenTelemetry 的 HTTP transport）默认不读取自定义 timeout header，你得自己 wrap roundtripper 或写 middleware 显式注入，否则链路里这一环就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
