JWT密钥须从环境变量加载并校验非空，解析时需区分ValidationError类型返回具体错误码，刷新Token应绑定单次有效的jti并存Redis，JWT认证须独立于Beego Session机制。
JWT签名密钥必须用环境变量加载，不能硬编码
Beego默认不提供JWT密钥管理机制，很多人直接在app.conf里写jwt_secret = my_super_secret_key，这会导致密钥随代码入库，测试/生产环境混用风险极高。更危险的是，Beego的beego.AppConfig.String("jwt_secret")若未配置会返回空字符串，jwt-go用空密钥签名后，所有token都能被伪造。
正确做法是：启动时从环境变量读取，缺失则panic：
secret := os.Getenv("JWT_SECRET")
if secret == "" {
panic("JWT_SECRET is required")
}
// 后续传给 jwt-go 的 SigningKey- CI/CD流程中通过Secret Manager注入，而非写入
.env文件 - 开发时用
export JWT_SECRET=$(openssl rand -hex 32)生成临时密钥 - 密钥长度建议≥256位（32字节），避免被暴力破解
Beego Controller里解析JWT要捕获jwt.ValidationError具体类型
直接用token, err := jwt.Parse(...)后只判断err != nil，会把过期、签名错误、算法不匹配等全部归为“认证失败”，前端无法区分重试还是重新登录。Beego中间件或Action里应显式检查错误类型：
if err != nil {
if ve, ok := err.(*jwt.ValidationError); ok {
switch ve.Errors {
case jwt.ValidationErrorExpired:
// 返回 401 + {"code": "token_expired"}
case jwt.ValidationErrorSignatureInvalid:
// 返回 401 + {"code": "invalid_signature"}
default:
// 其他如alg mismatch，按非法token处理
}
}
}- Beego的
Abort("401")不带响应体，需手动this.Data["json"] = map[string]string{...}再this.ServeJSON() - 不要依赖
token.Valid布尔值——它只检查签名和过期，不校验iss/aud等claim - 务必调用
token.Claims.(jwt.MapClaims)前做类型断言检查，否则panic
刷新Token必须绑定原Refresh Token的jti，且单次有效
Beego本身不提供refresh token存储方案，常见错误是仅校验新请求里的refresh_token签名和过期时间，导致一个refresh token可无限次换取新access token。安全做法是：在签发access token时，同时生成唯一jti（UUIDv4），存入Redis并设置与refresh token相同TTL；换取新token时，先查Redis是否存在该jti，存在则删除并签发新token，不存在则拒绝。
示例关键逻辑：
// 签发时
jti := uuid.New().String()
claims := jwt.MapClaims{
"jti": jti,
"exp": time.Now().Add(15 * time.Minute).Unix(),
}
redisClient.Set("refresh:"+jti, "valid", 7*24*time.Hour)
<p>// 换取时
val := redisClient.Get("refresh:" + jti).Val()
if val != "valid" {
this.Abort("401")
}
redisClient.Del("refresh:" + jti) // 单次有效- Redis key命名需带前缀（如
refresh:）避免冲突 - access token的
jti和refresh token的jti必须分离存储，不可复用同一字段 - 如果用MySQL存refresh token记录，务必加
used_at时间戳并建索引
Beego Session与JWT不能共用同一中间件拦截逻辑
很多开发者把JWT验证写成Beego的Prepare()方法，然后在同一个Controller里又调用this.StartSession()，结果发现session数据丢失或覆盖。根本原因是：Beego的session中间件默认读取Cookie，而JWT通常走Authorization: Bearer xxx头，两者认证源不同，但this.CruSession底层仍会尝试初始化session store（比如基于cookie的file session），造成干扰。
- JWT认证应独立于Beego Session机制，禁用
EnableSetCookie = true相关配置 - 若需用户状态持久化（如登出黑名单），用Redis存
blacklist:jti，而非依赖session - Beego的
xsrfkey和JWT无直接关系，但若开启XSRF保护，需确保前端在JWT请求头中携带X-Xsrftoken，否则Beego会拦截POST/PUT请求
JWT不是银弹，尤其在需要服务端主动失效token的场景下，Redis黑名单+短生命周期access token才是Beego项目里最可控的组合。别试图把JWT塞进Beego Session的抽象里。
