otel.Tracer 不能全局复用一个实例，因其按名称隔离追踪上下文，共用名称会导致 span 冲突、属性覆盖、采样策略失效；应按服务/模块使用专属名称如"user-service"，并通过依赖注入或 context 传递，避免包级缓存。
为什么 otel.Tracer 不能全局复用一个实例？
Go 的 otel.Tracer 实例本身是线程安全的，但它的语义是「按名称隔离追踪上下文」。如果你在所有地方都用 otel.Tracer("default")，不同模块、HTTP handler、消息消费者会混用同一个 tracer 名称，导致 span 名称冲突、属性覆盖、采样策略无法按服务区分。
- 每个服务/模块应使用专属名称，比如
otel.Tracer("user-service")或otel.Tracer("http-handler") - 不要在包级变量里缓存
otel.Tracer，而应在初始化时传入依赖（如 handler 构造函数参数）或通过 context 注入 - 若用
otel.GetTracerProvider().Tracer(...)，确保 tracer provider 已正确配置并注册了 exporter，否则返回的是 noop 实现，什么也不会上报
HTTP 中间件里怎么正确注入和提取 trace context？
OpenTelemetry 的 HTTP 追踪不是自动发生的，必须显式调用 propagation.HTTPTraceContext 来读写 traceparent 头。漏掉任一端，链路就会断成两截。
- 入口中间件（如 Gin/Mux）需用
propagator.Extract(r.Context(), r.Header)恢复 parent span - 出口调用（如
http.Client）前，必须用propagator.Inject(ctx, httpHeaderCarrier)写入头信息 - 别直接操作
r.Header.Get("traceparent")—— OpenTelemetry 的 propagator 会处理大小写、多值、W3C 格式校验等细节 - Gin 用户注意：
c.Request.Context()是干净的，要手动把 span 注入进去，再传给后续 handler；否则span := trace.SpanFromContext(c.Request.Context())会是 nil
otelhttp.Transport 和手动 Inject/Extract 有什么区别？
otelhttp.Transport 是 OpenTelemetry 官方提供的 HTTP client 透明埋点方案，但它只负责 outbound 请求；它不会帮你处理 inbound，也不控制 span 生命周期边界。很多人误以为装上就万事大吉。
- 它自动完成 Inject，但前提是你的请求 context 里已有有效 span（即你已在上游创建并设置了 span）
- 它默认把整个 HTTP roundtrip 包进一个 span，不区分 DNS、TLS、write、read 阶段——如需细粒度观测，得自己拆
- 它对重定向、连接复用、错误重试等行为有默认行为，但不会记录
http.status_text或自定义 header，这些得靠otelhttp.WithSpanOptions手动加 - 如果用了
otelhttp.Transport，就别再手动调用propagator.Inject，否则会重复写头、触发校验失败
本地开发时 trace 数据发不到 Jaeger/OTLP 后端？
最常见原因是 exporter 初始化早于 tracer provider 配置，或者环境变量没对齐。OpenTelemetry Go SDK 默认不 panic，失败时静默降级为 noop，你完全感知不到。
立即学习“go语言免费学习笔记（深入）”；
- 检查
otel.ExporterOtlpEndpoint是否指向正确的地址，比如本地 Jaeger 的 OTLP 接收端口是localhost:4317（不是 UI 端口 16686） - 确认
OTEL_EXPORTER_OTLP_ENDPOINT和代码中设置的 endpoint 一致；env 优先级高于代码硬编码，容易被覆盖 - Jaeger 0.10+ 默认关闭 OTLP 接收器，启动时要加
--otlp.grpc-port=4317 - 用
otel.SetErrorHandler注册一个打印日志的 handler，能立刻看到连接拒绝、证书错误、序列化失败等真实报错
复杂点在于 span 生命周期和 context 传递是隐式的，一旦某处忘了 context.WithValue 或用了错误的 context（比如从 time.AfterFunc 拿的），trace 就断了——这种问题没法靠日志一眼看出，得靠打点验证 context 是否携带 trace.SpanContext。
