opentelemetry go sdk是go链路追踪首选方案，需区分自动注入（http/grpc）与手动埋点（db/消息队列），tracerprovider须全局复用，context传span需确保下游显式读取，k8s部署需校准exporter地址与collector配置，trace_id/span_id默认随机生成即满足唯一性。
Go 里怎么用 OpenTelemetry 做链路追踪
直接上手：Go 官方推荐、社区主流、云厂商兼容性最好的方案就是 OpenTelemetry Go SDK，不是 Jaeger 原生客户端，也不是 Zipkin 直传——前者已停更维护，后者缺语义约定和上下文传播标准。
关键点在于「自动注入」和「手动埋点」的边界要划清：HTTP/gRPC 框架能自动抓 request ID 和 span context，但数据库调用、消息队列消费、本地方法耗时统计，必须手动加 span.AddEvent() 或新起 tracer.Start()。
- 别用
opentracing-go：它已归档，otelcol不再接收其数据，升级成本高 -
TracerProvider必须全局复用，不能每次请求都 new；否则 metrics 乱、exporter 连接泄漏 - HTTP 中间件里调
otelhttp.NewHandler()时，确保 handler 是最终业务 handler，不是嵌套在其他中间件之后的“半成品”
context.WithValue 传 span 会丢吗
会丢，而且很常见。Go 的 context.WithValue() 本身没问题，但问题出在「谁往 context 里塞了 span」以及「下游是否真的从 context 里取」。
典型翻车场景：你用 req.Context() 提取了 span，调了 db.QueryContext(ctx, ...)，结果链路断在数据库层——因为 database/sql 默认不读 context 里的 span，除非你用 go.opentelemetry.io/contrib/instrumentation/database/sql 包重写 driver，且显式调 otel.WrapDriver()。
- gRPC 客户端必须用
grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor())，光传 context 不够 - 自定义 goroutine 启动（比如
go func() { ... }()）必须显式传入带 span 的 context，不能依赖闭包捕获外层 context -
log.Printf()不会自动带 trace_id，得自己从trace.SpanFromContext(ctx).SpanContext().TraceID().String()拿出来打日志
为什么本地跑通了，上 K8s 就看不到完整链路
大概率是 exporter 配置没对齐：本地直连 localhost:4317，K8s 里服务发现走的是 service name，而你的 exporter endpoint 写死了 IP 或 localhost。
另一个高频原因是 span 被批量 flush 前进程就退出了——尤其在短生命周期服务（如 AWS Lambda、Knative）中，tp.Shutdown(context.Background()) 必须显式调，且不能被 defer 在 main 函数末尾（来不及执行）。
- 确认 exporter 使用
otlpgrpc.NewExporter()而非otlphttp：K8s service 默认不暴露 HTTP/2 端口，gRPC 更稳 - 检查 pod DNS 是否能解析 collector service：进容器
nslookup otel-collector.default.svc.cluster.local - collector 配置里
receivers.otlp.protocols.grpc.endpoint必须绑定0.0.0.0:4317，不能只写127.0.0.1:4317
trace_id 和 span_id 怎么保证全局唯一又可读
不用自己生成。OpenTelemetry Go SDK 默认用随机 128-bit trace_id + 64-bit span_id，完全满足分布式唯一性。你唯一要关心的是「可读性」要不要妥协——比如想让 trace_id 显示为时间戳+服务名前缀，这是反模式。
真正该做的是透传和关联：HTTP header 里必须用 traceparent（W3C 标准），而不是自定义 X-Trace-ID；gRPC metadata key 必须是 traceparent，不是 grpc-trace-bin（旧版 OpenTracing）。
- 别改
trace.IDGenerator：SDK 默认的随机生成器经过充分压测，自定义逻辑容易引入冲突或性能瓶颈 - 日志系统如果支持 OTel schema（如 Loki + Promtail 的
otel_attributes），直接把SpanContext.TraceID()当字段打，别转成 hex 字符串再切分 - 前端 JS SDK 发来的 traceparent，Go 后端用
otel.GetTextMapPropagator().Extract()就能自动续链，无需手动 parse
最常被忽略的一点：span 的 End() 时间戳默认是调用时刻，不是函数实际结束时刻。如果你在 defer 里 end span，但函数 panic 了，span 就永远不会结束——要用 recover() 捕获并强制 end。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
