traceid必须在echo中间件入口生成并注入：优先从x-trace-id或traceparent头提取，未命中则用uuid.newstring()生成；key须为私有类型，通过c.setrequest(c.request().withcontext(ctx))绑定回请求上下文，并写入响应头。
echo middleware 里怎么正确生成和注入 trace_id
trace_id 必须在请求入口就生成，且只能生成一次；不能等 handler 里再 new，也不能靠 context.Background() 覆盖掉原始请求上下文。
常见错误是：中间件里用 uuid.NewString() 生成 ID 后，只存进 ctx.Value()，但后续 handler 或 DB 调用没显式接收该 ctx，导致日志里 trace_id 字段为空。
- 定义全局 key：
type ctxKey string; const TraceIDKey ctxKey = "trace_id" - 中间件中生成并注入：
ctx = context.WithValue(c.Request().Context(), TraceIDKey, uuid.NewString()) - 必须把新
ctx绑定回c.SetRequest(c.Request().WithContext(ctx))（Echo v4.10+ 支持），否则下游c.Request().Context()拿不到 - 别用
rand.Int63()生成 trace_id——QPS 过万时碰撞率显著上升
为什么 otelhttp.NewHandler 包裹 echo.Handler 会失效
直接把 otelhttp.NewHandler(e.HTTPErrorHandler, "echo-handler") 当作中间件注册，span 名称会固定为 echo-handler，且无法关联真实路由、缺失 http.status_code 和 net.peer.ip 等关键属性。
根本原因是 Echo 的 echo.Echo 实例本身不是标准 http.Handler，它内部做了路由分发，otelhttp.NewHandler 只能包裹最终的 error handler，而非整个请求生命周期。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 正确做法：用官方支持的
echo-otel或rk-echo插件，例如rkecho.Interceptor() - 若坚持手写，必须 wrap 整个
echo.Echo的Server.Handler字段，而不是某个 handler 函数 - 出向 HTTP 调用必须替换 Transport：
http.DefaultClient.Transport = otelhttp.NewTransport(http.DefaultTransport)，否则下游 span 全断
zap 日志里 trace_id 总是空，是不是 context 没传对
是。zap 默认不读取 context，logger.Info("msg") 不会自动提取 trace.SpanFromContext(ctx)，必须显式调用 InfoCtx(ctx, "msg") 并确保 ctx 里有 OpenTelemetry 注入的 span。
更隐蔽的问题是：即使你用了 InfoCtx，如果中间件没把 span 注入到 request context（比如漏了 otelhttp.NewHandler 或没走 OTel 初始化流程），trace.SpanFromContext(ctx) 返回的就是空 span，SpanContext().TraceID().String() 也会是全零字符串。
- 初始化 logger 时要用
go.opentelemetry.io/contrib/instrumentation/zap提供的OTELZapCore - 所有日志调用都必须带
ctx：logger.InfoCtx(c.Request().Context(), "user login") - 别在 goroutine 里直接用外层 handler 的
ctx——要派生：ctx = context.WithTimeout(parentCtx, 5*time.Second) - 检查
otel.Tracer("my-service")是否在main()开头已注册TracerProvider，否则全程静默 fallback 到 noop
error 日志里 trace_id 对不上，是不是包装错了
大概率是。Go 原生 error 接口无法携带字段，fmt.Errorf("wrap: %w", err) 会丢掉 trace_id，而中间件捕获到的只是裸 error。
解决方案不是“每层都手动拼字符串”，而是让 error 类型自己持有 trace_id，并提供稳定提取方式。
- 定义
type tracedError struct { err error; traceID string }，实现Error()、TraceID() string和Unwrap() error - 在中间件或 handler 入口统一包装：
return &tracedError{err: err, traceID: getTraceID(c)} - 恢复中间件里用
errors.As(err, &tErr)提取 traceID，再注入日志或响应头 - 避免在日志里重复打 trace_id：中间件记录一次就够了，handler 里不要再用
log.WithField("trace_id", ...)补一次
ctx 或用了错的 ctx，trace 就断了，而且不会报错，只会默默消失。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
