Beego集成Jaeger需手动干预三处：HTTP入口Span创建与Context注入、跨服务SpanContext透传、中间件与http.Handler生命周期对齐；漏一则链路断裂。
Beego 框架集成 Jaeger 不是“配个 tracer 就完事”，关键在于三处必须手动干预：HTTP 入口的 Span 创建与 Context 注入、跨服务调用时的 SpanContext 透传、以及 Beego 中间件与原生 http.Handler 生命周期的对齐。漏掉任一环，链路就会在第一个中间件或第一个外部请求处断裂。
Beego 启动时初始化 Jaeger tracer 必须用 opentracing.SetGlobalTracer
Beego 不像 Gin 那样有显式中间件链入口，它的 App.Run() 底层仍走标准 http.Serve，所以 tracer 初始化必须在 main() 最早阶段完成，且必须调用 opentracing.SetGlobalTracer —— 否则所有 opentracing.StartSpanFromContext 都会 fallback 到 noop tracer，UI 里完全看不到数据。
常见错误是只创建了 jaeger.Tracer 实例但没设为全局，或者在 init() 里初始化却晚于 Beego 的自动路由注册。
- Reporter 端口必须匹配本地 Jaeger Agent：开发用
LocalAgentHostPort: "localhost:6831"，但jaegertracing/all-in-one默认监听6832（UDP），要不改容器启动参数加-p 6831:6831/udp，要不把配置改成"localhost:6832" - 生产环境禁用
Reporter.LogSpans: true，它会把每个 span 打成日志，干扰排查且吞吐扛不住；改用BufferFlushInterval: 1 * time.Second控制批量上报节奏 - 若跳过 Agent 直连 Collector，要用
jaeger.NewRemoteReporter+transport.NewHTTPTransport，端点是http://jaeger-collector:14268/api/traces，不是 UDP 端口
Beego Controller 中无法直接用 this.Ctx.Request.Context() 获取有效 Span
Beego 的 Controller 是复用实例，this.Ctx.Request 在每次请求中虽是新的，但 Beego 并未自动把上游 trace context 注入到该 request 的 context 中。如果你在 Get() 或 Post() 方法里直接调用 opentracing.SpanFromContext(this.Ctx.Request.Context())，几乎总是返回 nil。
正确做法是在自定义中间件里完成提取和绑定：
- 写一个
TracingMiddleware，类型为func(http.Handler) http.Handler，用beego.InsertFilter("/.*", beego.BeeAppHandler, TracingMiddleware, &beego.FilterRule{ReturnOnOutput: false})注册 - 中间件内先用
tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))尝试提取上游 context；失败则新建 root span - 用
opentracing.ContextWithSpan(r.Context(), span)构造新 context，再通过r = r.WithContext(newCtx)注入，最后next.ServeHTTP(w, r) - 务必在
defer span.Finish()前不修改w.Header()或写 body，否则某些 Beego 内置中间件（如 recover）可能 panic
Beego 调用 gRPC / HTTP Client 时必须手动注入 SpanContext
Beego 自身不处理下游调用的 context 透传。HTTP 客户端（比如 http.DefaultClient 或 resty）不会自动读取当前 span 并塞进 uber-trace-id header；gRPC 更是完全无感知。
这意味着：Beego 服务 A → HTTP 调用服务 B，若不手动注入，B 收到的请求就没有 trace id，链路在此断开。
- HTTP 调用前：获取当前 span
span := opentracing.SpanFromContext(r.Context())，然后tracer.Inject(span.Context(), opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(req.Header)) - gRPC 调用前：用
grpc_opentracing.GRPCTextMapPropagator将 span context 注入metadata.MD，再传给grpc.Dial的grpc.CallOption - MQ 场景（如 RabbitMQ）更需警惕：Producer 发送消息前必须把 span context 序列化进 message headers（如
X-B3-TraceId），Consumer 收到后用对应 extractor 反解，再调用StartSpan(..., opentracing.ChildOf(extractedCtx))
Beego 日志与 Jaeger tag 对齐容易被忽略
Beego 默认日志不带 trace_id，导致日志和链路无法关联。虽然 Jaeger UI 里能看到 span logs，但它们和 Beego 的 beego.Info() 日志是两套体系，搜索排查时得切两个界面。
最轻量的对齐方式是：在 tracing 中间件里提取出 traceID 后，把它塞进 Beego 的 context：this.Ctx.Input.SetData("trace_id", traceID)，然后在所有 beego.Debug/Info/Error 前统一 prepend [trace_id: xxx]。
更彻底的做法是替换 Beego 的日志 adapter，让每条日志自动携带 trace_id 和 span_id 字段，但这需要重写 beego.BeeLogger 的 writeMsg 流程，改动面较大，多数项目止步于第一种。
真正难的从来不是初始化 tracer，而是确保每一个跨 goroutine、跨协议、跨进程的调用点都严格透传 context —— Beego 的隐式生命周期和复用模型，会让这种透传更容易被绕过或遗忘。
