应使用 context.WithValue 配合私有类型 key（如 type userCtxKey string）存用户信息，而非 c.Set()；BasicAuth 与 JWT 中间件需统一写入同一类型安全 key；c.Get() 返回 nil 多因中间件未注册、顺序错误或执行中断。
中间件里怎么存认证后的用户信息
不能直接往 c 里塞任意字段（比如 c.Set("user", user)），虽然能用，但不安全也不规范。Echo 推荐用上下文值（context.WithValue）配合类型安全的 key，避免键名冲突或类型误读。
实际做法是定义一个私有类型作为 key：
type userCtxKey string const userKey userCtxKey = "auth_user"
在认证中间件中验证通过后，把用户结构体存进去：
c.Set(userKey, &User{ID: 123, Role: "admin"})
后续 handler 里用 c.Get(userKey) 取，记得做类型断言。别用字符串字面量当 key，否则拼错就静默失效。
BasicAuth 和 JWT 中间件怎么统一取用户信息
BasicAuth 和 JWT 是两个独立中间件，它们各自解析凭证、各自存用户，但如果你希望下游 handler 不关心来源，就得让它们写入同一个 key。
-
middleware.BasicAuth的回调函数里，验证成功后调用c.Set(userKey, user) -
echo_middleware.JWTWithConfig需自定义ContextExtractor和SuccessHandler，在SuccessHandler里同样写c.Set(userKey, user) - 不要依赖中间件默认行为——Echo 的
JWTWithConfig默认只设c.Set("user", claims)，key 名和类型都和你自己的不一致
关键点：统一 key、统一值类型、统一生命周期（都在中间件链中完成赋值）。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
为什么 c.Get("user") 有时返回 nil
常见原因不是逻辑错，而是中间件注册顺序或作用域问题：
- 中间件没
e.Use()全局注册，只挂到了某个Group，而 handler 在根路由下 - 用了
e.GET("/api", handler)但认证中间件只注册在v1 := e.Group("/v1")下，/api 就根本没过认证中间件 - handler 写在中间件之前，比如
e.GET("/", authMiddleware, handler)写反了顺序，导致handler执行时authMiddleware还没跑 - 跨中间件传递被中断：某个中间件 panic 或提前 return，后续中间件（包括你的用户设置逻辑）根本没执行
调试时加一行日志：fmt.Printf("set user? %v\n", c.Get(userKey) != nil)，放在认证中间件末尾和 handler 开头各打一次，就能定位断在哪。
API 和页面请求共用一套认证中间件要注意什么
浏览器页面请求要跳转登录页，API 请求得返回 401，但中间件本身不知道当前是哪种客户端。
必须在中间件里主动判断：
accept := c.Request().Header.Get("Accept")
if strings.Contains(accept, "text/html") {
// 是浏览器，重定向
c.Redirect(http.StatusFound, "https://auth.example.com/login?redirect_uri="+url.PathEscape(c.Request().URL.String()))
return
}
// 否则返回 JSON 错误
return c.JSON(http.StatusUnauthorized, echo.Map{"error": "unauthorized"})
别用 c.Path() 拼 redirect_uri，它不含 query；要用 c.Request().URL.String() 并做 URL 编码。这个判断逻辑必须在认证中间件内部做，不能丢给 handler —— 否则未认证请求根本进不到 handler。
