不能用字符串当 context key，因为不同包中同名字符串字面量（如"trace_id"）类型不一致，导致ctx.value("trace_id")恒返回nil；必须使用私有未导出类型（如type tracekey struct{}）并定义全局唯一变量（var tracekeykey = tracekey{}）作为key，取值时严格匹配该变量。
为什么不能用字符串当 context key
用 "trace_id" 这种字符串做 context.WithValue 的 key，会导致跨包取值失败——不同模块各自定义同名字符串 key，类型不一致，ctx.Value("trace_id") 永远返回 nil。Go 的 interface{} 比较依赖底层类型，字符串字面量在不同包里是不同实例。
必须用私有未导出类型作 key：
-
type traceKey struct{}（推荐，零内存开销） - 全局唯一变量：
var traceKeyKey = traceKey{} - 取值时严格匹配类型：
ctx.Value(traceKeyKey)，不能写成ctx.Value(traceKey{})（新 struct 实例 ≠ 全局变量）
HTTP 中间件里如何安全注入 TraceID
入口处不能只读 Header 就完事，必须把新 context 绑定到 *http.Request 上，否则下游框架（如 Gin、Chi）拿到的仍是原始 r.Context()。
关键三步缺一不可：
- 从
r.Header.Get("X-Trace-ID")读值，为空则 fallback 生成（如uuid.NewString()） - 用
context.WithValue(r.Context(), traceKeyKey, traceID)创建新 context - 调用
r = r.WithContext(newCtx)替换 request 的 context，再传给next.ServeHTTP
漏掉第三步，gin.Context.Request.Context() 或 chi.Context 里都拿不到这个值。
goroutine 启动时 TraceID 为什么会丢失
写 go doWork() 是最常见断链原因：新 goroutine 默认继承的是 context.Background()，不是你中间件里构造的那个带 TraceID 的 context。
修复方式只有两种，且必须显式传递：
-
go doWork(ctx)，函数签名必须接收ctx context.Context - 或在 goroutine 内部重新提取：
traceID := ctx.Value(traceKeyKey).(string)，再手动传参给子任务 - 禁止闭包捕获外部
ctx变量——它可能在 goroutine 启动前就被 cancel 或超时
数据库查询、HTTP client 调用、消息发送等所有异步操作，都必须走 db.QueryRowContext(ctx, ...) 或 client.Do(req.WithContext(ctx))，不能用 context.Background() 硬编码。
日志和 HTTP 出向请求如何自动透传
日志库（如 zap、slog）不会自动读 context，必须手动注入。常见错误是每条 log 都临时查一次 ctx.Value，性能差还易漏。
更稳妥的做法：
- 封装一个带 context 提取能力的 logger：
logger := zap.With(zap.String("trace_id", getTraceID(ctx))) - HTTP 出向请求不要手写
req.Header.Set("X-Trace-ID", ...)，改用统一工具函数：DoWithContext(ctx, req)，内部先取值再 set header - 若对接 OpenTelemetry，优先用
otelhttp.NewClient()，它会自动处理traceparent注入，比手动拼字符串可靠得多
真正难的不是注入，而是确保每个分支路径（error return、defer、recover）都传了同一个 context——只要有一处用了 context.Background() 或忘了传参，整条链就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
