JWT中间件仅解析token并存入Context，必须配合RBAC中间件校验角色；二者注册顺序不可颠倒，且ContextKey需严格一致，否则RBAC因取不到用户信息而panic。
JWT中间件本身不处理角色，必须配合自定义RBAC中间件才能实现角色认证——直接在echojwt.Config里加ContextKey只是第一步，漏掉后续校验逻辑等于没做。
echojwt.New() 必须设对 ContextKey 才能被 RBAC 读取
JWT中间件默认把解析后的用户信息存进c.Get("user")，但这个键名可配置。如果RBAC中间件硬编码读c.Get("claims")或c.Get("auth_user")，就会拿到nil然后panic。
-
ContextKey必须和RBAC中c.Get(...)用的字符串完全一致，大小写敏感 - 推荐显式指定，不要依赖默认值：
ContextKey: "user" - 如果JWT payload里嵌套了
roles字段（如{"user_id":123,"roles":["admin","editor"]}），确保它被完整塞进ContextKey指向的结构体里，而不是只存map[string]interface{}再手动解包
RBAC中间件必须在 JWT 之后注册，且不能跳过未认证请求
中间件顺序是硬性洋葱模型：请求进来时，echojwt必须先执行并往c里写入用户数据，RBAC才可能读到。如果把RBAC放在e.Use()最前面，或者误配成路由级中间件却忘了全局JWT，c.Get("user")永远是nil。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 正确顺序：
e.Use(middleware.Logger())→e.Use(echojwt.WithConfig(jwtConfig))→e.Use(rbacMw) - RBAC中间件里要检查
user == nil，直接返回401，别假设JWT一定成功 - 静态资源（如
/static/）或健康检查接口（如/healthz）若不需要鉴权，应单独定义路由，避开全局RBAC
角色校验逻辑写在中间件里，不是 handler 里
把if role != "admin" { return c.NoContent(403) }写在每个handler开头，会导致重复、遗漏、难以统一策略。RBAC中间件应该接管所有受保护路由的准入判断。
- 中间件内从
c.Get("user")取出结构体，断言为具体类型（如*User）比反复map[string]interface{}类型断言更安全 - 支持多角色时，用
slice遍历比strings.Contains查字符串更可靠（避免"editor"匹配到"supereditor"） - 错误响应建议复用
c.JSON(403, map[string]string{"error": "insufficient permissions"})，保持格式统一
测试 JWT + RBAC 组合时最容易漏掉的点
本地跑通不代表线上安全。真实环境里，token过期、签名密钥不一致、时钟偏差都会让JWT验证失败，进而导致RBAC拿不到用户数据。
- 用
curl -H "Authorization: Bearer invalid-token"测401是否由JWT中间件返回，而不是RBAC panic - 故意把
SigningKey设错，确认日志里出现invalid token而非panic: interface conversion - 在RBAC中间件开头加
if user == nil { return echo.NewHTTPError(http.StatusUnauthorized, "missing or invalid auth") }，堵住空指针漏洞
