必须用私有struct{}类型作key，因string key跨包不相等导致ctx.value返回nil；http中间件需r.withcontext更新请求，goroutine和grpc须显式透传，漏一处即断链。
不能靠中间件自动续传，必须每层显式提取 + 注入；字符串 key 必然失效，私有 struct{} 类型 key 是硬性前提；漏掉一次 WithContext 或 grpc.Metadata，链路就断。
为什么 string 类型的 context key 一定会失效
Go 的 context.Value 比较 key 是基于值相等（==），不是字符串内容。两个包各自定义 const key = "trace_id"，它们在内存中是不同实例，ctx.Value(key) 在下游永远返回 nil。
- 必须定义未导出的空 struct 类型：
type traceKey struct{} - 全局唯一变量：
var traceKeyKey = traceKey{} - 存取严格配对：
context.WithValue(ctx, traceKeyKey, "abc")和ctx.Value(traceKeyKey)，不能写成ctx.Value(traceKey{})（新实例 ≠ 全局变量） - 别用
type ctxKey string—— 不同包定义的同名类型不兼容，仍会断链
HTTP 中间件里如何安全注入并向下传递
只读 header 不算完成，关键在把新 context 绑定回 *http.Request，否则 Gin、Chi 等框架拿到的仍是原始 r.Context()。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先解析
traceparent（W3C 标准），格式为00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01，从中取第 2 段作为 trace ID - fallback 到
X-Trace-ID，再 fallback 到X-Request-ID（注意：后者不保证唯一，仅保底） - 调用
context.WithValue(r.Context(), traceKeyKey, traceID)创建新 context - 必须执行
r = r.WithContext(newCtx)，再传给next.ServeHTTP(w, r) - Gin 用户注意：
c.Request = c.Request.WithContext(newCtx)，不能只改c.Request.Context()
goroutine 和 gRPC 调用时 trace 字符串为什么会突然消失
go func() { ... } 默认继承 context.Background()，不是你中间件构造的那个带值的 context；gRPC 的 metadata.MD 也不会自动映射到 ctx.Value。
- 启动 goroutine 时必须显式传参：
go doWork(ctx)，函数签名要接收ctx context.Context - 禁止闭包捕获外部
ctx变量——它可能已被 cancel 或超时 - gRPC 客户端调用前，用
metadata.Pairs("x-trace-id", traceID)构造metadata.MD，再通过grpc.MetadataCarrier注入ctx - gRPC 服务端拦截器中，用
metadata.FromIncomingContext(ctx)提取，再context.WithValue注入 handler 使用的 context - 所有 DB 查询、HTTP client 请求，必须用
db.QueryRowContext(ctx, ...)或client.Do(req.WithContext(ctx))，不能硬编码context.Background()
日志和异步任务如何桥接 context 中的字符串值
zap、logrus、slog 都不会自动读 context，手动每条 log 查 ctx.Value 性能差且易漏；异步任务若没显式传参，字符串值就丢了。
- 封装复用 logger：
logger := zap.With(zap.String("trace_id", getTraceID(ctx)))，避免重复提取 -
getTraceID应做安全断言：v, ok := ctx.Value(traceKeyKey).(string); if !ok { return "" } - 消息队列投递（如 Kafka、RabbitMQ）时，把 trace 字符串塞进 message headers 或 metadata 字段，消费端再注入 context
- 定时任务或后台 worker 启动时，若依赖请求上下文，必须从触发源（如 HTTP 入口）完整透传，不能在 worker 内部生成新 context
最常被忽略的是：HTTP 中间件里做完 WithValue 却忘了 r.WithContext，或者 gRPC 客户端写了 context.WithValue 却没走 metadata——这两处一漏，整条链路的字符串数据就归零。无侵入不是不写代码，而是把透传逻辑收拢到统一入口和封装函数里，别让它散落在业务 handler 或 goroutine 闭包中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
