Revel框架JWT认证应使用github.com/golang-jwt/jwt/v5，因其修复了旧版安全漏洞、维护活跃且兼容RFC 7519；需通过拦截器（Filter）统一校验Authorization头中的Bearer Token，解析后存入c.Params.Values供Controller安全读取，避免重复解析或硬编码密钥。
Revel框架里JWT认证该用哪个库
Revel 本身不内置 JWT 支持，得靠第三方库补足。最常用、维护较活跃的是 github.com/dgrijalva/jwt-go（v3.2.x），但注意它已归档，新项目建议迁移到 github.com/golang-jwt/jwt/v5。Revel 的拦截器（Filter）机制是接入 JWT 的核心，别试图在 Controller 里重复校验——那样会漏掉静态资源或中间件前的请求。
常见错误现象：jwt.Parse 返回 nil + token is invalid，但实际是密钥类型不匹配（比如用 []byte 解析时传了字符串）、时间戳校验失败（服务器和客户端时间差超 VerifyAt 容忍范围），或算法不一致（签发用 HS256，解析却指定 RS256）。
如何写一个可靠的 JWT 拦截器
把校验逻辑放在 app/init.go 的 init() 函数里注册为 REVEL_INTERCEPTOR，优先级设为 revel.BEFORE。拦截器必须处理三类情况：无 Token、Token 无效、Token 有效但 payload 缺关键字段（如 user_id）。
- 检查
AuthorizationHeader 是否存在且格式为Bearer <token>，别直接用r.Header.Get("Authorization")然后硬切分——空格或大小写异常会导致 panic - 调用
jwt.Parse时，keyFunc必须返回与签发时完全一致的密钥；若用HS256，密钥长度建议 ≥32 字节，否则 Go 的 crypto/hmac 会静默降级 - 解析成功后，把
claims（通常转成map[string]interface{}或自定义 struct）存进c.Params.Values，供后续 Controller 使用，别塞进c.Session—— JWT 本身是无状态的
Controller 怎么安全读取用户身份
不要在每个 Action 里重复解析 Token。拦截器已把解析结果挂到上下文，Controller 只需从 c.Params.Values 取值。典型错误是直接断言 v, ok := c.Params.Values["user_id"].(float64) —— JWT 的数字型字段默认解析为 float64，但更稳妥的做法是用 json.Number 或显式转 int64：
if userIDRaw, ok := c.Params.Values["user_id"]; ok {
if userIDFloat, ok := userIDRaw.(float64); ok {
userID := int64(userIDFloat)
// 后续业务逻辑
}
}
如果需要关联数据库用户，应在拦截器里完成查库并缓存到 c.Params.Values，避免 Controller 里二次查询造成延迟；但注意别把敏感字段（如密码哈希）一并塞进去。
刷新 Token 和黑名单怎么处理
Revel 没有内置 session 存储，JWT 刷新必须靠双 Token（Access + Refresh）机制。Refresh Token 应存服务端（如 Redis），Key 为 "refresh:" + user_id，值存签发时间戳和 jti；每次刷新 Access Token 时，先校验 Refresh Token 是否在 Redis 中且未过期，再签发新 Access Token 并更新 Redis 中的过期时间。
黑名单实现的关键点：
- 黑名单只存被主动注销的 jti（不是整个 Token），节省空间
- Redis 过期时间 = Access Token 过期时间 + 一定缓冲（如 5 分钟），防止时钟漂移导致误判
- 拦截器中校验完签名后，立即查 Redis：
redisClient.SIsMember(ctx, "jwt_blacklist", claims["jti"]).Val()，命中则拒绝访问
别指望靠修改 Revel 的 Session 实现黑名单——它默认基于 Cookie，无法跨服务共享，且 JWT 设计本意就是无状态，强行混用反而破坏架构一致性。
