必须用 r.WithContext() 替换原请求，否则下游拿不到新 context；traceKey 必须是私有 struct；HTTP 下游调用需手动透传 header 和 context；日志需手动注入 TraceID 字段。
中间件里必须显式用 r.WithContext() 替换原请求
很多人在 Echo 中间件里调用 context.WithValue() 后，业务 handler 依然拿不到 TraceID，根本原因是：Echo 的 next.ServeHTTP(w, r) 传的是原始 *http.Request，它内部的 r.Context() 还是旧的。你不改 r，下游永远看不到新 context。
正确做法是构造新 request：
- 先用
context.WithValue(r.Context(), traceKey{}, traceID)创建新 ctx - 再调用
r = r.WithContext(newCtx)—— 这一步不可省，WithContext()返回新 request，原对象不变 - 最后传给
next.ServeHTTP(w, r)
漏掉第二步，整个链路就断了。别信“中间件里设了 value 就自动生效”这种直觉。
traceKey{} 必须是私有 struct，不能用字符串
用 string 当 key（比如 "trace_id"）会导致跨包冲突：A 包和 B 包都用同样字符串 key 写 value，后写的会覆盖前写的，或者取的时候类型断言失败 panic。
标准解法是定义私有空 struct 作 key：
type traceKey struct{}
然后统一用 &traceKey{} 作为 key 参数传给 WithValue() 和 Value()。这样即使不同模块定义同名 struct，地址也不一样，完全隔离。
常见错误包括：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 用
"trace_id"字符串直接当 key - 用
type traceKey string—— 底层还是字符串，不解决冲突 - key 定义在多个文件里复制粘贴，导致实际是不同类型（但编译能过，运行时失效）
HTTP 客户端发起下游调用时，header 和 context 都要手动处理
Echo 本身不干涉你发 HTTP 请求。如果你在 handler 里用 http.Client.Do() 调其他服务，context.Context 不会自动变成 header，header 也不会自动注入 context —— 这两件事都得你亲手做。
典型流程是：
- 从当前 ctx 取值：
traceID := ctx.Value(&traceKey{}).(string)，注意判空防 panic - 写入 request header：
req.Header.Set("X-Trace-ID", traceID)，别用Add()，避免重复 - 发起请求时绑定 context：
client.Do(req.WithContext(ctx))，否则超时/取消逻辑失效
如果用了 resty 或 gorequest，它们默认完全忽略 context；必须手动 .SetHeader("X-Trace-ID", traceID)，且不能依赖其自动透传。
日志不打 TraceID，不是 Context 没传，是 logger 没“读”
很多团队查了半天 context 传递，最后发现日志里始终没 trace_id —— 其实 context 已经一路传到底了，只是 log.Printf()、fmt.Println() 或没配置好的 zap 日志器压根不看 context。
必须让日志器主动从 ctx 提取：
- 用
zap时，加zap.String("trace_id", traceID)手动注入字段 - 用
zerolog时，通过ctx.Logger().Info().Str("trace_id", traceID).Msg(...)方式 - 不要指望任何日志库“自动感知 context”，Go 标准库 log 更是完全无感
最易被忽略的点：链路追踪成败不取决于中间件写得有多漂亮，而在于最后一行日志有没有带上那个 ID。没它，所有 span 都是孤岛。
