Revel 中需手动解析 Authorization Header 的 Bearer Token：先用 c.Request.Header.Get("Authorization") 获取，严格校验前缀为"Bearer "，截取后 trim 空格，再用 golang-jwt/jwt/v5 验证签名与 claims，并在拦截器中注入用户信息至 c.RenderArgs，失败时必须显式调用 c.Unauthorized()。
Revel 框架本身不内置 JWT 支持，但可以通过中间件 + jwt-go（或更现代的 golang-jwt/jwt/v5）手动集成，关键在于拦截请求、提取并验证 Token，再把用户信息注入到 revel.Controller 上下文中。它不像 SpringBoot 那样有 @PreAuthorize 或自动配置，每一步都得自己串起来，稍有疏漏就会导致 401 不生效、用户信息拿不到、或签名验证被绕过。
怎么在 Revel 中提取和解析 Authorization Header 的 Token
Revel 的 HTTP 请求处理链中，Token 通常放在 Authorization: Bearer <token></token> 头里。你不能依赖框架自动拆解，必须手动读取、切分、校验格式：
- 用
c.Request.Header.Get("Authorization")获取原始头值，不是c.Params.Get("auth")—— 后者根本不存在 - 检查前缀是否为
"Bearer "（注意末尾空格），不是"bearer"或"Bearer:"，大小写和空格都要严格匹配 - 截取后半段时用
strings.TrimSpace()清理首尾空格，避免ParseUnverified解析失败 - 若 Token 格式错误（比如少一段、含非法字符），
jwt.Parse会直接 panic，建议先做长度判断或用strings.Count(token, ".") == 2快速过滤
用 golang-jwt/jwt/v5 验证签名并提取 claims
旧版 jwt-go 有严重安全漏洞（如 CVE-2020-26160），必须用 v5 版本。验证逻辑不能只调用 Parse 就完事，要显式指定算法、提供密钥、并检查 Valid 字段：
- 初始化
jwt.NewValidator时，Valid方法必须返回true才算通过；仅解析成功 ≠ Token 有效 - 密钥类型必须与签发时一致：HS256 用
[]byte，RS256 用*rsa.PublicKey，混用会导致KeyFunc returned an invalid key -
exp和nbf声明默认不自动校验，需传入jwt.WithValidatorOptions(jwt.WithValidTime()) - 别直接用
token.Claims.(jwt.MapClaims)强转，应定义结构体实现jwt.Claims接口，避免字段名拼错或类型不匹配
如何把用户信息挂到 Revel Controller 上并做权限拦截
Revel 的 Controller 是每次请求新建的，所以不能全局存用户，而要在每个请求生命周期内“注入”——最稳妥方式是写一个自定义拦截器（revel.Interceptor），并在其中设置 c.Params.Values["user_id"] 或扩展 c 的字段：
- 不要往
c.Session写用户 ID：Session 是 Cookie 驱动的，和 JWT 无状态理念冲突，且容易引发跨域/移动端兼容问题 - 推荐在拦截器中解析成功后，调用
c.RenderArgs["user"] = user，然后在 Action 里用user := c.RenderArgs["user"].(*User)取值 - 权限控制逻辑（如角色判断）应放在拦截器里，而不是每个 Action 开头手写
if user.Role != "admin"，否则极易遗漏 - 拦截器注册顺序很重要：JWT 验证拦截器必须在路由匹配之后、Action 执行之前，即用
revel.BEFORE阶段，不能用revel.FINISH
为什么 Token 过期后前端仍能访问接口？
常见原因是服务端没正确返回 401，或者前端没处理响应状态码。Revel 默认对验证失败只打印日志，不会中断请求流：
- 在 JWT 拦截器里，一旦
jwt.Parse返回 error，必须显式调用c.Result = c.Unauthorized()或c.Abort(401)，否则请求会继续往下走 - 别依赖
panic或 log.Fatal 来中断流程——Revel 会 recover 并返回 500，这不是客户端预期的认证失败语义 - 前端若用 fetch，需检查
response.status === 401后主动清空本地 Token；若只监听error事件，会漏掉 401 这类“成功响应但业务失败”的情况 - 时钟偏移（clock skew）也会导致误判过期，v5 版本支持
jwt.WithLeeway(60 * time.Second)容忍 1 分钟误差
真正难的不是生成或解析 Token，而是让整个请求链路里的每个环节都“信任”这个字符串：从 Header 提取的健壮性、签名验证的完整性、用户上下文传递的一致性、错误响应的语义准确性——缺一不可。任何一个环节松动，都会让鉴权形同虚设。
