Echo 中间件链 Span 容易断掉是因为默认不自动传递 context.Context 中的追踪信息，需手动完成提取、创建、注入三步传播，否则跨服务调用或子 Span 将丢失。
为什么 Echo 的中间件链里 Span 容易断掉
因为 Echo 默认不自动传递 context.Context 中的追踪信息，你在 handler 里用 ctx := r.Context() 拿到的 context 是原始 HTTP 请求上下文，不含 Span。如果没在中间件里显式注入、提取和传递 trace context，跨服务调用或子 Span 创建后就“失联”了——Jaeger 或 OpenTelemetry UI 里只看到孤零零一个入口 Span，后续全丢。
必须手动做 Context Propagation 的三个关键点
OpenTelemetry 和 Jaeger 都不会替你自动往 HTTP Header 里塞/读 traceparent 或 uber-trace-id，Echo 也不内置这个逻辑。你得自己写中间件完成三件事：
- 从入站请求 header 中提取 trace context（比如用
otel.GetTextMapPropagator().Extract()） - 用该 context 创建 root Span（若无 parent）或 child Span（若有）
- 把新 context 注入到
c.Request().WithContext()，确保后续 handler 和子调用能继承
漏掉任意一步，链路就断。常见错误是只做了提取，没做注入；或者用了 c.Set("span", span) 这种自定义字段，但下游 gRPC/HTTP 调用时根本没把 span 传出去。
HTTP 出站调用时怎么保证 Span 不丢
你用 http.Client.Do() 调其他服务时，context.Context 里的 trace context 不会自动写进 request header。必须手动注入：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
req, _ := http.NewRequestWithContext(ctx, "GET", "http://svc-b/users", nil) otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header)) client.Do(req)
别依赖任何 “自动传播” 插件——Echo 生态没有官方 OTel HTTP client middleware。如果你用的是 resty 或 greq，也得查它是否支持 WithContext + HeaderCarrier 注入，否则一律 fallback 到原生 http.Client 手动处理。
采样率和 Span 命名别硬编码在中间件里
把 Tracer.Start() 的 trace.WithSpanName("echo-handler") 写死，会导致所有路由共用一个 Span 名，无法区分 /api/user 和 /api/order。正确做法是动态取路由名：
spanName := c.Request().URL.Path
if route := c.HandlerName(); route != "" {
spanName = route // 或用 c.Param("*") 提取通配路径
}
_, span := tracer.Start(ctx, spanName, trace.WithSpanKind(trace.SpanKindServer))
采样策略也别写成 AlwaysSample() 上生产——高流量下打爆 Collector。用 ParentBased(TraceIDRatioBased(0.01)) 更稳妥，既能保关键链路，又控数据量。
最常被忽略的其实是异步任务：goroutine 里直接用 go func(){ ... }() 启动的逻辑，会丢失父 context。必须用 go func(ctx context.Context){ ... }(ctx) 显式传入，再用 otel.GetTextMapPropagator().Inject() 注入 header，否则后台任务永远游离在 Trace 之外。
