echo.Context不是标准库context.Context，而是Echo框架自定义的HTTP上下文接口；需通过c.Request().Context()获取标准context.Context用于DB等操作。
echo.Context 不是标准库 context.Context
很多人一看到 echo.Context 就默认它是 Go 标准库的 context.Context，这是最常踩的第一个坑。它俩名字撞车，但完全不是一回事：echo.Context 是 Echo 框架自己定义的请求上下文接口，封装了 HTTP 请求/响应、路由参数、中间件链等 Web 层能力；而 context.Context 是 Go 并发控制用的底层信号载体，负责超时、取消和值传递。
你不能把 echo.Context 直接当 context.Context 传给数据库驱动（比如 db.QueryContext(ctx, ...)），也不能拿它去调用 ctx.Done() —— 它压根没实现那个接口。
真正该做的是：在 echo.Context 的 handler 里，从它内部取出真正的 context.Context：
func(c echo.Context) error {
ctx := c.Request().Context() // ← 这才是标准库 context.Context
rows, err := db.QueryContext(ctx, "SELECT ...")
// ...
}
echo.Context.Value() 和 context.Context.Value() 容易混用
echo.Context 也提供了 Value(key interface{}) interface{} 方法，但它和 context.Context.Value() 是两套独立存储，互不感知。如果你在中间件里用 c.Set("user_id", 123)，然后在 handler 里调 c.Get("user_id")，没问题；但若试图用 c.Request().Context().Value("user_id") 去取，一定返回 nil。
立即学习“go语言免费学习笔记（深入）”；
反过来说，你在 handler 里用 context.WithValue(c.Request().Context(), "trace_id", "abc") 注入的值，echo.Context 的 Get() 也拿不到。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 需要跨中间件/处理器共享数据 → 用
echo.Context.Set()/Get() - 需要向下透传到 DB、RPC、HTTP client 等标准库函数 → 必须用
context.WithValue(c.Request().Context(), ...)，并确保后续调用链都接收并使用这个ctx - 不要在
echo.Context上存大量结构体或闭包，它不是为高性能键值存储设计的
中间件中修改 context.Context 要重新绑定回 request
当你在中间件里派生新的 context.Context（比如加 trace ID、设置超时），必须手动把它塞回 *http.Request，否则下游 handler 拿到的还是原始 context：
func TraceMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
req := c.Request()
ctx := req.Context()
traceID := generateTraceID()
ctx = context.WithValue(ctx, "trace_id", traceID)
// ⚠️ 关键一步：替换 request 的 context
req = req.WithContext(ctx)
c.SetRequest(req) // ← 否则 next(c) 仍用旧 ctx
return next(c)
}
}
漏掉 c.SetRequest(req) 是高频错误。Echo 不会自动同步两个 context 的变更，它只在初始化 handler 时调一次 c.Request().Context()。
另外注意：context.WithTimeout 或 WithCancel 创建的新 context，其 Done() 通道一旦关闭，所有基于它的子操作（如 DB 查询）都会立即中断 —— 这是预期行为，但得确保你已正确 defer cancel()，否则可能泄露 goroutine。
echo.Context 生命周期比 context.Context 短得多
echo.Context 实例是每次 HTTP 请求新建的，请求结束就回收（被 GC）；而它内部包裹的 context.Context 可能来自 Background()、WithTimeout() 或上游服务注入，生命周期由 cancel 逻辑决定。这意味着：
- 别在 goroutine 里长期持有
echo.Context引用（比如启动后台任务后还传它），请求一结束，c.Response()写入就会 panic - 如果要异步处理，只提取必要字段（如
c.Param("id")、c.Request().URL.Path）或拷贝一份context.Context，再显式传参 - 日志中间件里记录
c.Request().Context().Err()时，要判断是否为nil，避免空指针
最隐蔽的问题是：你以为在 handler 里启动了一个 goroutine 并传了 c，结果它还在跑时请求早已返回，c 对应的 response writer 已失效，任何写操作都会 crash。
