Jaeger客户端初始化报nil pointer dereference的根本原因是未调用opentracing.SetGlobalTracer注册tracer实例，导致全局tracer为nil；HTTP链路需用HTTPClientOption/HTTPServerOption自动透传uber-trace-id；goroutine中须显式传递带span的context；UDP reporter默认静默丢包，需替换为LoggerReporter或CompositeReporter并检查网络连通性。
Jaeger 客户端初始化为什么总报 nil pointer dereference
根本原因是没正确初始化 tracer 就直接调用 opentracing.StartSpan。OpenTracing 是接口层，不自带实现；Golang 里必须先用 Jaeger 的 jaeger.NewTracer 构建一个具体实例，并通过 opentracing.SetGlobalTracer 注册，否则全局 tracer 是 nil。
实操建议：
- 初始化必须在 main 函数早期完成，且早于任何 span 创建逻辑
- 别跳过
opentracing.SetGlobalTracer—— 这步不是可选的“配置”，是必填的“绑定” - 检查返回的
tracer是否为nil，尤其当jaeger.NewTracer参数错误（如 agent 地址不可达）时，它可能静默返回nil而非 panic
示例关键片段：
tracer, closer, err := jaeger.NewTracer(
"my-service",
jaeger.NewConstSampler(true),
jaeger.NewUDPTransport("localhost:6831", 0),
)
if err != nil {
log.Fatal(err)
}
defer closer.Close()
opentracing.SetGlobalTracer(tracer) // ← 这行漏掉，后面全崩
HTTP 请求怎么自动注入和提取 trace context
手动传 span.Context() 到 header 再解析太容易漏、错位或污染业务逻辑。应该用 OpenTracing 提供的 HTTPClientOption 和 HTTPServerOption 做透明透传。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 客户端发请求前，用
opentracing.HTTPClientRoundTripper包裹原http.Transport，它会自动写入uber-trace-idheader - 服务端接收请求时，用
opentracing.HTTPServerMiddleware（或手动调opentracing.GlobalTracer().Extract）从 header 读 context 并生成 child span - 注意：默认 header key 是
uber-trace-id，不是trace-id或X-Trace-ID，改 key 需同步配 Jaeger 的TracerOptions
常见错误现象：链路断成两截，后端 span 显示 parent 为 nil —— 大概率是服务端没做 Extract，或客户端没做 Inject。
goroutine 里启动 span 为什么 trace 丢失
OpenTracing 的 span 绑定在当前 goroutine 的上下文（context.Context），但 Go 的 go func() {}() 不会自动继承父 goroutine 的 span。新 goroutine 默认没有 active span，opentracing.SpanFromContext(ctx) 返回 nil。
实操建议：
- 显式把 span 作为参数传进去，或把带 span 的
context.Context传进去（推荐后者） - 用
opentracing.ContextWithSpan把 span 注入 context，再传给新 goroutine - 避免在 goroutine 内直接调
opentracing.StartSpan—— 它默认 parent 是 nil，导致链路断裂
错误写法：go doWork()；正确写法：go doWork(opentracing.ContextWithSpan(ctx, span))。
Jaeger reporter 写入失败但程序不报错
Jaeger 的 UDP reporter 默认是 fire-and-forget 模式，发包失败（比如 agent 未启动、端口被占、网络不通）不会 panic，也不会 log，只默默丢弃数据。你看到 span 在代码里创建了，但 Jaeger UI 里完全没记录，大概率是这个原因。
实操建议：
- 开发期加
jaeger.NewLoggerReporter替换默认 reporter，它会把发送失败打到 stdout - 生产环境用
jaeger.NewRemoteReporter+jaeger.NewCompositeReporter组合 logger reporter，确保可观测性 - 检查本地网络连通性：
nc -u localhost 6831应该不报错（UDP 不保证回显，但至少不提示 connection refused）
最容易被忽略的一点：Jaeger agent 默认只监听 localhost，Kubernetes 里 service 的 endpoint 是 cluster IP，必须显式设 --reporter.local-agent-host-port=jaeger-agent:6831 才能跨 pod 上报。
