应先校验 token.Valid 为 true 且 Signature 非空，再断言 jwt.MapClaims 并检查 "roles" 字段是否存在、类型是否为 []interface{}，逐个转 string；角色必须由服务端签发时写入，不可信前端。
JWT token 解析后怎么安全提取角色字段
直接从 token.Claims 断言成 jwt.MapClaims 再取 "role" 或 "roles" 是常见写法，但隐患很大：字段名不统一、类型错误、缺失校验都会导致 panic 或越权。必须先做类型断言+存在性检查+值合法性验证。
- 用
token.Claims.(jwt.MapClaims)前，先确认token.Valid为true，且token.Signature != "" - 角色字段推荐固定用
"roles"（数组），避免单角色字段（如"role"）无法扩展；解析时用claims["roles"].([]interface{})，再逐个转成string - 不要信任前端传来的任何字段——JWT payload 可被解码查看，角色必须由服务端签发时写入，且只从签发方可信源生成的 token 中读取
Echo 的 JWT 中间件如何透传角色信息给后续 handler
Echo 自带的 jwt.Middleware 默认只校验签名和过期时间，不解析或挂载用户数据。你需要自定义一个中间件，在验证通过后把角色列表塞进 c.Request().Context()，而不是依赖全局变量或中间件外解析 token。
- 用
c.Set("roles", roles)最轻量，后续 handler 用c.Get("roles")取；比塞 context 更符合 Echo 习惯 - 若需强类型，可定义
type UserClaims struct { Roles []string `json:"roles"` }，在中间件里用token.Claims.(*UserClaims)断言（需提前注册该结构） - 别在每个 handler 里重复解析 token——中间件只做一次解析+校验+注入，否则性能浪费且易出错
RBAC 权限检查该放在路由层还是 handler 内部
权限判断逻辑必须前置到路由匹配之后、handler 执行之前，否则可能绕过校验（比如 handler 内部才 check，但 panic 或 early return 导致跳过）。Echo 没有原生 RBAC 中间件，得自己封装一个基于角色的访问控制中间件。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 推荐按 HTTP 方法 + 路径做权限映射，例如
map[string]map[string][]string{"GET": {"/api/users": {"admin", "manager"}}} - 中间件中先取
c.Get("roles").([]string)，再查当前请求方法+路径是否在允许角色列表中；不匹配就直接c.NoContent(http.StatusForbidden) - 避免在 handler 里写
if !hasRole("admin") { return }——分散、难维护、容易漏，且无法统一审计日志
为什么不能把权限规则硬编码在中间件里
硬编码角色数组（如 []string{"admin"}）看似简单，但一上线就卡死迭代：新增角色、调整接口权限、灰度放行都得改代码+重启。真实项目里权限规则必须可配置、可热更新。
- 把权限策略存进 Redis 或数据库，结构建议用
permission:<method>:<path></path></method>→["admin","editor"]，每次请求查一次（加本地缓存，TTL 30s） - 启动时加载全量规则到内存 map，配合文件监听或 webhook 实现热重载；避免每次请求都走网络 IO
- 注意并发安全：用
sync.RWMutex包裹规则 map，读多写少场景下性能影响极小
最常被忽略的一点：JWT 里的角色只是“身份声明”，不是“权限本身”。真正决定能不能删用户的是「角色→权限」映射规则，这个映射一旦写死在 token 里，就彻底失去动态管控能力。
