Gin 的 c.Request.Context() 默认不携带 trace_id，因其底层是 http.Request 创建的干净 context，不自动解析上游 header 中的 traceparent 或 X-Trace-ID；必须通过中间件手动提取、用 context.WithValue() 注入并赋值 c.Request = c.Request.WithContext(newCtx) 才能透传。
Gin 本身不自动透传分布式链路上下文（如 trace_id、span_id），必须手动注入和提取，否则跨服务调用时链路会断裂。
为什么 Gin 的 c.Request.Context() 默认不携带 trace_id
Gin 的 *gin.Context 底层包装了 http.Request，而标准库的 http.Request.Context() 是每次新请求创建的干净 context，不会继承上游传递的 trace 信息。即使上游通过 HTTP Header（如 traceparent 或 X-Trace-ID）传来了 trace_id，Gin 也不会自动解析并塞进 context。
- 常见错误现象：下游服务日志里 trace_id 是空或随机生成的新值，Jaeger / Zipkin 中看不到完整调用链
- 根本原因：缺少中间件解析 header 并调用
context.WithValue()构建带 trace 的新 context - 注意：
c.Request = c.Request.WithContext(newCtx)才能让后续 handler 和中间件拿到更新后的 context
如何用中间件实现 trace_id 的注入与透传
需在入口处读取 header，构造带 trace 的 context，并确保下游 HTTP 请求也带上对应 header。
- 提取：检查
c.Request.Header.Get("X-Trace-ID")或traceparent（W3C 标准），若为空则生成新 trace_id - 注入：用
context.WithValue(c.Request.Context(), keyTraceID, traceID)创建新 context，再调用c.Request = c.Request.WithContext(newCtx) - 透传：调用下游服务时（如用
http.Client），需手动设置 header：req.Header.Set("X-Trace-ID", traceID) - 建议封装 key：用私有变量
var keyTraceID = struct{}{}避免字符串 key 冲突
c.Set() 和 context.WithValue() 到底该用哪个
二者用途完全不同，混用会导致链路丢失。
-
c.Set("trace_id", v)：只在当前*gin.Context生命周期内有效，无法穿透到http.Client发起的下游请求中 -
context.WithValue(c.Request.Context(), key, v)：真正影响整个请求生命周期，包括中间件、handler、以及你主动发起的任何子请求 - 错误示范：仅用
c.Set()记录 trace_id，然后在日志中间件里用c.GetString("trace_id")—— 日志能打出来，但下游服务收不到 - 正确做法：所有链路相关数据（trace_id、span_id、sampled）都走
context.WithValue()，并在需要发起 HTTP 调用前从 context 取出写入 header
Go 标准库 context 的泄漏风险要特别小心
每次调用 context.WithValue() 都会新建一个 context 实例，但 Go 的 context 不支持删除 key，一旦写入就伴随整个请求生命周期。
- 避免往 context 塞大量业务数据（比如用户完整 profile），只放必要链路标识字段
- 不要用
context.Background()或context.TODO()替代c.Request.Context()，否则上游 trace 信息彻底丢失 - 如果你用了 opentelemetry-go，优先使用
otel.GetTextMapPropagator().Extract()解析 header，它会自动处理 W3C 标准格式，比手写更可靠
最易被忽略的一点：HTTP 客户端发起调用时，必须显式把当前 context 中的 trace 信息注入 request header，Gin 不会帮你做这件事——它连 http.Client 都不碰。
