不能直接将echo.Context存入结构体或全局变量，因其源自sync.Pool的临时对象，仅存活于单次请求；跨请求复用会导致内存泄漏、数据竞争及panic。
为什么不能直接把 echo.Context 存到结构体或全局变量里
因为 echo.Context 是从 sync.Pool 中获取的临时对象，生命周期只覆盖单次请求处理。一旦 handler 返回、响应写出完成，它就会被归还池中复用。如果你在中间件里把它塞进 map、chan 或结构体字段，或者启动 goroutine 并传入 c，会导致：
- 对象无法归还，GC 压力持续升高
- 多个请求共享同一
c实例，引发数据竞争或脏读 - 下游调用
c.JSON()时 panic："http: Handler returned nil" 或 "use of closed network connection"
c.Set() + c.Get()，且 key 必须类型安全（比如定义 type ctxKey string）。
c.Set() 和 c.Get() 怎么避免类型断言 panic
直接写 c.Get("user_id").(int64) 很危险——如果 key 不存在、值是 nil、类型不匹配，运行时就 panic。必须加显式类型检查：
if userID, ok := c.Get("user_id").(int64); ok {
// 安全使用 userID
} else {
// 处理缺失或类型错误，比如返回 400 或 log.Warn()
}
更稳妥的做法是定义类型安全 key：
type userIDKey string
const userIDKey = "user_id"
// 中间件中设置
c.Set(userIDKey, int64(123))
// handler 中取值
if userID, ok := c.Get(userIDKey).(int64); ok {
// ✅ 类型已由编译器约束，不会误塞 string 进去
}
自定义 Context 类型要怎么注册才不破坏中间件顺序
自定义 Context（比如 *CustomContext）本质是包装原生 echo.Context，但它的中间件必须注册在所有其他中间件之前。否则后续中间件拿到的是原始 echo.Context，你的扩展方法根本不可见。
错误写法（CustomContext 中间件放后面）：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
e.Use(authMiddleware) // 拿到的是原始 c e.Use(customCtxMiddleware) // 此时再包一层，但 authMiddleware 已经执行完了
正确顺序：
- 先注册
customCtxMiddleware - 再注册日志、鉴权、限流等所有依赖自定义方法的中间件
- handler 里强制类型断言：
cc := c.(*CustomContext)，然后调cc.Foo()
注意：不要在 CustomContext 方法里调 c.Set() 或修改原 c 字段——这会绕过 Echo 的上下文管理机制，导致行为不可预测。
中间件里调 c.Set() 后，handler 为啥有时拿不到值
常见原因有三个：
-
中间件没生效：比如注册在
group.Use()里，但请求路径不匹配该 group 前缀 -
key 名拼错或大小写不一致：比如中间件设
c.Set("UserID", 123)，handler 却查c.Get("userid") -
中间件 abort 了请求：比如鉴权失败调了
c.NoContent(403)或return nil，后续中间件和 handler 都不会执行，c.Set()虽然执行了，但没人来读
调试建议：在中间件末尾加一行日志 log.Printf("set user_id=%v", userID)，再在 handler 开头打日志看是否执行——能快速定位是“没设”还是“没读到”。
echo.Context 的生命周期和类型安全不是语言强制的，全靠开发者自觉。一个 c.Set() 写错 key 名，可能让整条链路静默失效，而编译器完全不报错。 
