必须用c.setrequest(c.request().withcontext(...))将新context写回http.request；tracekey须为私有struct类型，日志、http调用、goroutine均需显式传递该context，禁止handler fallback生成traceid。
中间件里必须用 c.SetRequest(c.Request().WithContext(...)) 替换 request context
很多人写了中间件读 X-Trace-ID，也调了 context.WithValue()，但 handler 里 c.Request().Context().Value(traceKey{}) 还是 nil。根本原因是没把新 context 绑回 *http.Request —— Echo 的 echo.Context 只是壳，真正透传靠的是底层 http.Request.Context()。
正确做法只有这一种：
- 从 header 提取或生成 traceID
- 调用
context.WithValue(c.Request().Context(), traceKey{}, traceID) - 再用
c.SetRequest(c.Request().WithContext(newCtx))写回去（echo v4.10+支持；老版本需反射或升级） - 别依赖
c.Set("trace_id", ...)，它只存 echo.Context 自己的 map，不进标准 context
traceKey 必须是私有 struct 类型，不能是字符串
用 "trace_id" 当 key 是最常见翻车点：不同中间件、第三方库可能用相同字符串 key，导致值被覆盖或类型断言失败。
安全写法只有一种：
- 定义
type traceKey struct{}（注意空 struct，无字段） - 注入时用
context.WithValue(ctx, traceKey{}, id) - 取值时必须显式类型断言：
if id, ok := ctx.Value(traceKey{}).(string); ok { ... } - 别省略
ok判断 ——ctx.Value()返回interface{}，类型不匹配会 panic
日志器、HTTP 客户端、goroutine 都得显式用带 TraceID 的 context
中间件设好了，handler 里也能取到，但日志还是没 trace_id？问题常出在日志器是全局单例，没绑定当前请求上下文。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
关键不是“加字段”，而是“换上下文”：
- 用
zerolog.Ctx(req.Context())或zap.L().With(zap.String("trace_id", id))构造请求级 logger - 下游 HTTP 调用必须透传：
req = req.WithContext(c.Request().Context())，再http.DefaultClient.Do(req) - 启动 goroutine 时，别直接
go func() {...}()，要go func(ctx context.Context) {...}(c.Request().Context()) - OpenTelemetry 用户优先用
otel.GetTextMapPropagator().Inject()注入traceparent头，兼容性更好
别在 handler 里 fallback 生成 TraceID，链路就断了
中间件已统一注入，handler 就该只取，不该再判断空、再生成。否则异步调用、重试、子请求都会拿到不同 ID，链路分裂。
典型错误模式：
- 中间件没设默认 ID，header 缺失时留空 → handler 里补 uuid → 与上游不一致
- 多个中间件各自生成 ID，后一个覆盖前一个
- 日志打在 middleware 外层（如全局 panic 捕获），此时 context 已丢失
真正可靠的链路，所有环节都只信任中间件注入的那个 context.Context，其他地方一律不碰生成逻辑。
