必须用 e.use() 注册中间件并在其中调用 c.request().withcontext() 替换 request context，否则下游 c.request().context() 拿不到注入值；echo.context 与 http.request.context() 是两层独立结构，前者不自动同步后者。
必须用 e.Use() 注册中间件，并在中间件内调用 c.SetRequestID()（或手动 c.Request().WithContext()），否则下游 handler 里 c.Request().Context() 拿不到注入的值——这是最常被忽略的断点。
为什么 echo.Context 和 http.Request.Context() 是两层东西
echo.Context 是框架封装的接口，它内部持有 *http.Request；而真正参与 goroutine 透传、超时控制、值携带的是 http.Request.Context()。你调用 c.Get("req_id") 或 c.Value("req_id") 读的是 echo.Context 自己的 map 或 valueCtx，和标准库 context 无关。只有显式调用 r.WithContext(newCtx) 并重新赋回 request，下游的 c.Request().Context() 才能拿到新 context。
- echo v4 默认不自动同步
echo.Context和http.Request.Context() -
c.Set("key", val)只写入 echo.Context 的局部 map，不会影响底层 request context - 所有依赖
context.WithValue()传递的数据（如X-Request-ID、user.ID）必须走req.WithContext()
RequestID 中间件里怎么正确注入 context
不能只靠 c.SetRequestID()（那是 echo 自带方法，只设 header 和内部字段）。要链路追踪生效，必须生成 ID 后创建新 context，并替换 request：
- 用
uuid.NewString()或类似方式生成唯一 ID - 调用
context.WithValue(r.Context(), reqIDKey, id)创建新 context - 再调用
r = r.WithContext(newCtx)，然后c.SetRequest(r)（注意：echo v4.10+ 支持该方法；老版本需用反射或直接改结构体字段，不推荐） - 最后别忘了写 header：
c.Response().Header().Set("X-Request-ID", id)
示例关键片段：
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
func RequestIDMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
id := uuid.NewString()
req := c.Request()
ctx := context.WithValue(req.Context(), "req_id", id)
req = req.WithContext(ctx)
c.SetRequest(req) // 必须这一步
c.Response().Header().Set("X-Request-ID", id)
return next(c)
}
}
下游 HTTP 调用如何继承这个 context
如果你在 handler 里发起另一个 HTTP 请求（比如调用其他服务），必须显式把当前 context 带进去，否则新请求的 req.Context() 还是 background：
- 用
http.NewRequestWithContext(c.Request().Context(), ...)构造请求 - 不要用
http.NewRequest()+ 后续.WithContext()，容易漏掉 - 下游服务也得做同样 context 注入逻辑，否则链路就断在第一跳
- 如果用了
rk-echo等扩展包，它会自动从 header 提取X-Request-ID并注入 context，但前提是你的上游已正确下发 header 且你调用了它的中间件
容易被忽略的 context 泄漏点
最隐蔽的问题不是“没传”，而是“传了但没 cancel”：
- 用
context.WithCancel()或WithTimeout()创建子 context 后，必须确保在 handler 返回前调用cancel()，否则 goroutine 和 timer 会长期驻留 - echo 中间件函数本身不提供 defer 作用域，cancel 必须在 handler 内部显式调用，或包装成闭包管理
- 数据库查询、RPC 调用等阻塞操作若未传 context，会绕过超时控制，导致整个请求 hang 住
-
context.WithValue()的 key 建议用私有类型（如type reqIDKey struct{}），避免字符串 key 冲突
链路是否真正贯通，不看日志有没有打印 ID，而要看每个 goroutine 里 ctx.Value(reqIDKey{}) 是否始终可取——这需要每一层都严格遵循 request context 替换和透传规则，少一个环节，整条链就断了。
