Echo 的 Context 是请求生命周期内的临时对象，Set() 存的键值对仅在当前请求链中有效，必须确保所有访问都发生在同一 Context 实例上；常见错误是中间件与 handler 使用了不同封装的 Context 实例，导致 Get() 返回 nil。
Context.Set() 存值后为什么在中间件里取不到？
Echo 的 Context 是请求生命周期内的临时对象，Set() 存的键值对只在当前请求链中有效，但必须确保所有访问都发生在同一个 Context 实例上。常见错误是：在中间件里调用 c.Set("user", u)，但在后续 handler 里用了另一个被封装过的 c（比如被自定义 wrapper 包了一层却没透传 Set / Get），导致 c.Get("user") 返回 nil。
实操建议：
- 始终使用原始 Echo
echo.Context实例，避免自行包装时遗漏Set/Get方法代理 - 检查中间件执行顺序：用户信息注入中间件必须在依赖该信息的中间件或 handler 之前注册
- 用
if v := c.Get("user"); v != nil判空，而不是直接断言类型，避免 panic
如何安全地把用户信息存进 Context 并类型断言？
存的是 interface{}，取的时候要类型安全。Echo 不提供泛型 Get[T]()（v4.10+ 仍无），所以必须手动断言。直接写 c.Get("user").(*User) 风险高——一旦 key 不存在或类型不对就 panic。
推荐写法：
if userIface := c.Get("user"); userIface != nil {
if user, ok := userIface.(*User); ok {
// 安全使用 user
c.JSON(200, map[string]interface{}{"name": user.Name})
return
}
}
c.JSON(401, map[string]string{"error": "unauthorized"})
注意点：
- 不要在
Set()前做指针取地址操作（如&u），除非你明确需要指针语义；多数场景存*User更合理，避免拷贝大结构体 - 如果用户信息来自 JWT 解析，建议在验证中间件里完成解析、校验、赋值三步，不要拆到多个中间件里
Context 存用户信息 vs 全局 map 或 goroutine-local storage？
别用全局 map（如 map[string]*User）存用户信息来“模拟 session”，这是反模式：不自动清理、无请求隔离、并发读写需额外锁、无法和 Echo 生命周期对齐。
goroutine-local（如 gls 库）也不必要——Echo 的 Context 本身已绑定到当前 goroutine 请求流，且自带取消机制和超时控制。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
真正该考虑的是：
- 是否真需要把整个
*User放进 Context？有时只需UserID（int64或string），handler 再按需查库，更可控 - 敏感字段（如密码哈希、token）绝不要塞进 Context，哪怕只是临时存在
- Context 适合存轻量、只读、请求级上下文数据；持久状态（如用户偏好）应走 Redis 或 DB，Context 只存 ID 或缓存句柄
Context 跨中间件传递用户信息的实际注册顺序
Echo 中间件执行顺序直接影响 Set() 和 Get() 是否可见。典型安全链路是：JWTAuth → UserLoader → Handler。
错误示例（UserLoader 在 JWTAuth 前）：
e.Use(UserLoader) // 此时 c.Get("token") 还没设，会失败
e.Use(JWTAuth)
正确顺序：
e.Use(JWTAuth) // 解析并 Set("token", raw)
e.Use(UserLoader) // 从 token 提取 sub，查 DB，Set("user", u)
e.GET("/profile", profileHandler)
关键点：
- 每个中间件内部若修改了
c（比如重写了c.Request），必须返回新c或确保原实例未被丢弃 - 调试时可加日志：
log.Printf("in %s: user=%v", "UserLoader", c.Get("user"))，确认各环节值是否存在 - Context 不能跨 goroutine 传递（比如启新 goroutine 后传 c 进去），会引发 panic 或数据错乱
最易被忽略的一点：Context 生命周期严格绑定于 HTTP handler 执行过程，一旦 handler 返回，Context 就不可再安全使用——哪怕你在 defer 里调 c.Get()，也可能读到已释放内存（尤其开启 GC 优化时）。存用户信息只为当下这次响应服务，别想复用。
