echo.Context自带生命周期管理、值存储和响应控制能力，其c.Value()与c.Request().Context()完全隔离；跨中间件传递元数据应统一用c.Set()/c.Get()，调用标准库（如database/sql、http.Client）时才需c.Request().Context()。
echo.Context 不是 request.Context 的简单包装，它自带生命周期管理、值存储和响应控制能力；不理解这点，就容易在中间件里存错数据、漏调 c.Next()、或误用 c.Request().Context()。
为什么 c.Value() 存的数据在中间件外取不到？
因为 c.Value() 是 echo.Context 自己的键值存储，和 c.Request().Context() 完全隔离。很多开发者以为往 c.Request().Context().WithValue() 里塞东西，下游 handler 就能通过 c.Value() 拿到——这是错的。
-
c.Value(key)只能读取由c.Set(key, val)或其他中间件显式写入的值 - 若需跨中间件传递请求级元数据（如用户 ID、trace ID），统一用
c.Set("user_id", 123)+c.Get("user_id") - 不要在中间件里直接操作
c.Request().WithContext(...)，除非你明确要覆盖底层 net/http 的 context（比如加超时）
什么时候该用 c.Request().Context()，而不是 c?
真正需要 c.Request().Context() 的场景极少，只出现在必须对接标准库生态时：
- 调用
database/sql方法：必须传c.Request().Context()，不能传c - 启动带取消的 goroutine（如异步日志上报）：用
c.Request().Context().Done()监听请求终止 - 调用第三方 HTTP 客户端（如
http.Client.Do）：必须用c.Request().Context()，否则超时/取消不生效 - 别在
c.Value()里存大对象（如[]byte原图），改存指针或 ID；否则 GC 压力会随并发上升
中间件里忘记调 c.Next() 会怎样？
不是“跳过后续逻辑”，而是整个请求链提前终止——handler 根本不会执行，且无错误提示，curl 看起来像卡住或直接 500。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 典型错误写法：
if !authOK { c.JSON(401, "unauthorized"); return }—— 缺少return后没调c.Next()，但 handler 仍会被执行 - 正确写法：前置校验失败后，必须
return并确保不进入c.Next()分支 - 调试技巧：在第一个中间件开头打 log，结尾打 log，看是否成对出现；不成对说明某处漏了
c.Next()或提前return - 注意：
c.Next()是同步调用，不是 goroutine；它按注册顺序逐个触发下一个中间件或最终 handler
如何安全地复用 Context 避免 GC 压力？
Echo 默认每次请求新建 echo.Context 实例，高并发下 GC 明显。启用上下文池可缓解，但有前提条件：
- 必须在
e := echo.New()后立即调用e.Use(middleware.Recover())（recover 中间件内部依赖池） - 手动启用池：
e.Pre(echo.MiddlewareFunc(func(next echo.HandlerFunc) echo.HandlerFunc { return next }))—— 这会触发 Echo 内部的 context 复用逻辑 - 禁用默认 Logger 中间件（
e.Logger.SetOutput(ioutil.Discard)），改用异步 zap 日志，否则日志写入会成为瓶颈 - 验证是否生效：pprof 查看
echo.(*context).Reset调用次数，应远高于new(context)
最常被忽略的一点：Context 生命周期严格绑定于单次 HTTP 请求；任何试图把它保存到 goroutine、map 或全局变量里的操作，都会导致数据混乱或 panic。哪怕只是存个 *echo.Context 指针，也等同于把 request 对象泄露到请求之外。
