应通过类型化 key 安全存取：定义 ctxKey 常量，用 c.Set(key, value) 存、c.Get(key).(Type) 断言取；JWT 与 RBAC 中间件须分离且顺序正确；权限标识统一用 "resource:action" 扁平格式。
Context里怎么安全存取用户信息
Echo 的 c.Get() 返回 interface{}，直接断言会 panic。必须先判断 key 是否存在、类型是否匹配：if u, ok := c.Get("user").(User); ok。推荐定义类型化 key：type ctxKey string; const userKey ctxKey = "user"，中间件中用 c.Set(userKey, user) 存，handler 中用 c.Get(userKey) 取——避免和标准库 context.WithValue 混用导致 key 冲突。
JWT中间件和RBAC中间件为什么不能合并
JWT 中间件只做一件事：解析 token、校验签名和过期时间，然后把用户结构体塞进 c；RBAC 中间件只做另一件事：从 c 里取出用户 ID，查数据库或缓存拿到权限 map（比如 map[string]struct{}{"post:read": struct{}{}}），再检查当前路由所需权限是否存在。两者职责必须分离：e.Use(echojwt.WithConfig(jwtConfig)) 必须在前，e.Use(rbacMiddleware) 必须在后。如果合并，token 解析失败时 RBAC 逻辑可能误判为“无权限”而非“未登录”，返回 403 而非 401。
为什么 RequirePermission("user:read") 传的是权限码不是角色名
RBAC 的核心是“权限驱动”，不是“角色驱动”。RequirePermission 接收的参数是具体操作码（如 "user:delete"），不是 "admin" 这类角色名。因为一个角色可能对应多个权限，一个接口也可能需要多个权限（比如编辑用户需 "user:read" + "user:update"）。权限码应与路由行为强绑定，例如 POST /posts 对应 "post:create"，而不是模糊的 "writer"。权限 map 存成 map[string]struct{}，检查用 _, ok := perms["post:delete"]，比遍历 slice 快且无副作用。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
OPTIONS预检请求和免鉴权路由怎么不翻车
硬写 if path == "/login" || path == "/health" 是维护陷阱。正确做法是用 e.Group("") 注册所有免鉴权路由（登录、注册、健康检查、Swagger），再用 auth := e.Group("/api") 注册需鉴权的路由，并只在 auth.Use(...) 上挂 JWT 和 RBAC 中间件。这样 OPTIONS 请求天然被排除在外——它不会命中任何 handler，Echo 默认返回 204。若必须混用（如遗留系统），则自定义跳过标记：c.Set("skip_jwt", true)，并确保该中间件放在 JWT 中间件之前；但要注意，skip_jwt 不影响 CORS 或日志中间件，它们仍会执行。
关键点在于：Context 是传递用户上下文的载体，不是鉴权逻辑本身；权限检查必须基于运行时解析出的具体权限码，而非静态角色名；路由分组隔离比路径字符串判断更可靠，尤其在有动态参数（/users/:id）或代理转发（Nginx 过滤 header）的场景下。
