go服务中trace id不跨goroutine传递的正确做法是用oteltrace.contextwithspan注入span并启用opentelemetry传播器，而非context.withvalue；需配置propagator、exporter，并确保span正确结束。
Go 服务里 trace ID 不跨 goroutine 传递？用 context.WithValue 是错的
Go 的 context.Context 本身不保存 trace 数据，直接往里面塞 trace.Span 或 trace.TraceID 是常见误区。真正该做的是用 OpenTracing / OpenTelemetry 的 context 包装器——比如 oteltrace.ContextWithSpan 或旧版 opentracing.ContextWithSpan，它们会把 span 注入 context 并确保在 goroutine 切换时自动传播。
常见错误现象：span.SpanContext().TraceID().String() 在子 goroutine 里为空或变成新 trace ID；HTTP handler 里有 trace，但 go func() { ... }() 里丢失。
- 必须用
oteltrace.SpanFromContext(ctx)获取当前 span，而不是从 context.Value 手动取 - 启动子 goroutine 前，用
ctx = oteltrace.ContextWithSpan(ctx, span)显式注入 - HTTP 中间件、数据库驱动、RPC 客户端等组件需启用 OTel 自动插桩（如
otelhttp.NewHandler、otelsql.Open）
OpenTelemetry Go SDK 初始化时漏掉 propagators，上下游 trace 就断了
trace 跨服务串联靠的是 HTTP header 透传（如 traceparent），而 Go SDK 默认不启用任何 propagator。没配 otel.SetTextMapPropagator，你的服务收不到上游 trace ID，也发不出下游 trace ID，整条链就碎成单点。
使用场景：微服务间 HTTP 调用、gRPC、消息队列（如 Kafka）生产/消费。
- 必须调用
otel.SetTextMapPropagator(otelpropagation.NewCompositeTextMapPropagator(otelpropagation.TraceContext{}, otelpropagation.Baggage{})) - 若只用 W3C TraceContext（推荐），可简写为
otel.SetTextMapPropagator(otelpropagation.TraceContext{}) - gRPC 场景下还需注册
otelgrpc.WithPropagators到 client/server 选项中
为什么 otel.Tracer("my-service") 创建的 tracer 没生效？检查 OTEL_TRACES_EXPORTER 环境变量
OpenTelemetry Go SDK 是“无操作”默认实现：不设 exporter，Tracer 创建成功但所有 span 都被静默丢弃。你看到日志里没报错，但 Jaeger / Zipkin / OTLP 后端收不到任何数据，大概率是这个原因。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
参数差异：OTEL_TRACES_EXPORTER=otlp 对应 OTLP 协议（推荐），OTEL_TRACES_EXPORTER=jaeger 对应 Jaeger Thrift（已逐步弃用）。
- 本地调试可用
OTEL_TRACES_EXPORTER=logging把 span 打到 stdout，确认 tracer 是否真在工作 - 生产环境优先选
otlp+OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318/v1/traces - 别漏掉
OTEL_SERVICE_NAME=my-order-service，否则后端无法按服务名聚合
gin 或 echo 中间件里手动创建 span，却忘了结束或 recover panic？trace 会卡死
手动创建 span 后忘记调用 span.End()，或者中间件 panic 导致 defer span.End() 不执行，会造成 span 泄露、内存增长、采样率失真，严重时拖垮 collector。
性能影响：未结束的 span 会持续占用内存并阻塞 exporter 批处理队列。
- 必须用
defer span.End()，且放在 handler 函数最开头（不是 middleware init 阶段） - 用
recover()包裹 handler 执行逻辑，并在 panic 时显式调用span.RecordError(err)和span.End() - 更稳妥的做法是直接用官方适配器：
otelgin.Middleware("my-api")，它已内置 panic 捕获和 span 生命周期管理
复杂点在于 trace propagation 和 span 生命周期必须与 Go 的并发模型对齐，稍一松懈就断链或泄露。别指望“初始化一次就完事”，每个 HTTP handler、每个 goroutine、每个第三方库调用点，都得检查上下文是否携带 span、是否正确结束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
