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()。立即学习"go语言免费学习笔记（深入）"；gRPC 客户端必须用 grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor())，光传 context 不够自定义 goroutine 启动（比如 go func() { ... }()）必须显式传入带 span 的 context，不能依赖闭包捕获外层 contextlog.Printf() 不会自动带 trace_id，得自己从 trace.SpanFromContext(ctx).SpanContext().TraceID().String() 拿出来打日志为什么本地跑通了，上 K8s 就看不到完整链路大概率是 exporter 配置没对齐：本地直连 localhost:4317，K8s 里服务发现走的是 service name，而你的 exporter endpoint 写死了 IP 或 localhost。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能