Revel框架不内置JWT支持，需禁用默认SessionFilter并手动实现JWT解析、上下文注入与权限校验，避免混用导致安全错乱。
Revel 框架本身不内置 JWT 认证支持，必须手动集成；它默认的 session 机制（基于加密 cookie）和无状态 JWT 是两种不同范式，混用会导致 SecurityContext 错乱、Filter 链失效或权限校验被跳过。
Revel 中 JWT 认证要绕开默认 session 过滤器
Revel 启动时自动注册 revel.InterceptFunc 和 revel.SessionFilter，它们会强制读写 session cookie 并初始化 revel.Ctrl.Session。如果你在后续 filter 中解析 JWT 并设置用户上下文，但前面的 SessionFilter 已经把空 session 或伪造 session 写入响应头，就可能干扰前端 Token 携带逻辑，甚至触发 401 重定向（尤其在 app.Init 里没禁用时）。
- 必须在
app.Init()中显式禁用默认 session：revel.Interceptors = append(revel.Interceptors, revel.SessionFilter)这行要删掉或注释 - 改用自定义中间件（
revel.InterceptFunc）在revel.BEFORE阶段提取Authorization: Bearer <token></token> - JWT 解析失败时，直接调用
c.Abort(401)，不要依赖revel.SessionFilter的 fallback 行为
JWT 解析与用户上下文注入必须手动完成
Revel 没有类似 Spring Security 的 SecurityContext 或 Authentication 对象抽象，所有认证信息需由你塞进 c.Params 或挂载到 c 上——但要注意生命周期和并发安全。常见错误是把解析出的 user_id 存进 c.Session（这又绕回 cookie 机制），或直接赋值给 c.User（该字段未被框架识别，后续 filter 无法感知）。
- 推荐做法：在自定义 JWT filter 中解析成功后，将用户 ID、角色等关键字段存入
c.Params.Set("user_id", "123")和c.Params.Set("roles", []string{"editor"}) - 避免使用
c.Session.Set()，否则会触发Set-Cookie响应头，破坏无状态契约 - 若需跨 action 复用，可封装一个
GetUser(c *revel.Controller) (*User, error)工具函数，内部从c.Params提取并查库补全用户信息
接口级权限控制只能靠手动判断或自定义拦截器
Revel 不提供 @PreAuthorize 或 hasRole() 这类声明式注解，也没有 URL 模式匹配的权限白名单机制。所有授权逻辑必须显式写在 controller action 开头、或统一收口到一个 AuthzFilter 里——后者更可控，但容易漏配。
- 在
AuthzFilter中检查c.Params.Get("roles")，比对当前请求路径是否在允许列表中（如/api/v1/admin/**→ 要求admin角色） - 路径匹配建议用
path.Match而非字符串Contains，避免/user/delete被/user规则误放行 - RBAC 权限项（如
project:write）应存在数据库，filter 中查出用户全部权限后做map[string]bool快速判断，别每次请求都查库 - 切记：
c.RenderError(403)或c.Abort(403)后必须 return，否则后续逻辑仍会执行
Token 刷新与登出在 Revel 里没有现成方案
JWT 无状态特性决定了服务端无法主动使 Token 失效。Revel 又不自带 Redis 客户端或黑名单管理模块，所以“退出登录”只能靠前端清空本地存储 + 后端配合短有效期（如 15 分钟）+ Refresh Token 双发机制。但 Revel 的路由和参数绑定不原生支持 /auth/refresh 这类专用 endpoint 的 clean 实现。
- Refresh Token 应独立签发（不同密钥、更长有效期），且只在
/auth/login和/auth/refresh接口返回，绝不混在 Access Token 的claims里 - 登出接口（
/auth/logout）实际只需返回成功，真正的“登出”靠前端删除localStorage中的 Token，并确保后续请求不再携带 - 如需强登出（如改密码后废止所有 Token），必须自行接入 Redis，把
jwt_id（即jticlaim）加入黑名单，每次解析 JWT 前先查redis.Exists("jti:" + jti)
Revel 的轻量带来灵活性，也把 JWT 全链路细节甩给了开发者：从 Header 提取、签名验算、载荷解码、上下文注入、权限匹配到 Token 管理，每一步都得自己写、自己测、自己兜底。最容易被忽略的是 SessionFilter 的残留影响和 c.Params 生命周期边界——这两个点一旦出错，整个认证流程就会静默失效，连日志都难定位。
