Beego默认不内置JWT支持，需手动集成golang-jwt/jwt/v5；关键在FilterFunc中安全校验并注入用户上下文，避免Prepare()中鉴权、正确处理panic场景、密钥配置与刷新陷阱。
Beego 默认不内置 JWT 支持，但可以基于 github.com/dgrijalva/jwt-go（注意：该库已归档，生产环境建议迁移到 github.com/golang-jwt/jwt/v5）手动集成；关键难点不在生成 token，而在拦截器中安全提取、校验并注入用户上下文——稍有疏忽就会绕过鉴权或泄露敏感字段。
Beego 中如何正确注册 JWT 鉴权中间件
Beego 的 FilterFunc 是唯一可控的请求入口点，必须在 main.go 的 beego.InsertFilter() 中注册，且顺序不能晚于 session 初始化（否则可能被 session 覆盖或干扰）。常见错误是把鉴权逻辑写在 controller 的 Prepare() 里，这会导致未登录用户仍能进入方法体，仅靠返回值拦截已不安全。
推荐做法：
- 用
beego.InsertFilter("/*", beego.BeeApp.Handlers, jwtAuthFilter, true)全局注册，true表示前置执行 - 过滤器内优先检查请求头
Authorization字段，格式应为"Bearer xxx"，忽略空格和大小写差异 - 若路径匹配白名单（如
/api/v1/login、/api/v1/register），直接return放行，不校验 token - 校验失败时调用
ctx.Abort(401)并写入统一错误响应，避免暴露jwt.Parse的底层错误信息
解析 JWT 时必须处理的三个典型 panic 场景
jwt.ParseWithClaims() 在输入非法、签名失效或过期时不会返回 error，而是让 token.Valid 为 false，同时 token.Claims 可能为 nil —— 直接断言类型会 panic。
安全写法要点：
Token 消耗追踪工具。当用户需要监控 API token 使用情况、生成每日/每周消耗报告、分析使用趋势时使用此 Skill。功能包括：自动记录每次对话的 token 消耗、生成数据表格报告、计算使用趋势和预测、支持定时推送日报。
- 先判断
err != nil（如 token 格式错误、base64 解码失败） - 再判断
token != nil && token.Valid == false，此时需区分是Expired还是SignatureInvalid，可通过errors.Is(err, jwt.ErrTokenExpired)判断（v5 版本） - claims 断言前务必加
if claims, ok := token.Claims.(jwt.MapClaims); ok，不要硬转自定义结构体，除非你 100% 控制 payload 结构 - 禁止从 claims 中直接取
user_id等字段后不做非空校验就查库，否则可能触发空指针或 SQL 注入（如果拼接进 raw query）
JWT 密钥与过期时间在 Beego 中的配置方式
密钥不能硬编码在代码里，应从 conf/app.conf 读取，并设为环境变量兜底。Beego 的 beego.AppConfig.String("jwtkey") 可安全获取，但要注意：
-
app.conf中写jwtkey = "dev-secret-123"，开发环境可用；生产环境必须通过JWTKET=prod-secret-xxx环境变量覆盖 - 过期时间建议拆成两个配置项：
jwt_expire_seconds = 3600（access token）和jwt_refresh_seconds = 604800（refresh token），避免所有 token 共用一个 TTL - 密钥长度必须符合算法要求：HS256 要求至少 32 字节（256 bit），
len([]byte(key)) < 32会导致签名被轻易伪造 - Beego 启动时应校验密钥是否为空或过短，
if len(key) < 32 { panic("jwt key too short") }
刷新 Token 的实现陷阱与替代方案
原生 JWT 不支持“主动失效”，所谓“刷新”本质是签发新 token 并丢弃旧 token —— Beego 项目里没人管旧 token，只要它没过期就一直有效，这是最大安全隐患。
可行对策：
- 不依赖单个 long-lived token，改用短时效 access token（如 15 分钟）+ 长时效 refresh token（如 7 天），且 refresh token 必须绑定设备指纹（
User-Agent+IP哈希）存 DB 校验 - refresh 接口必须验证旧 refresh token 的有效性，且成功后立即在 DB 中将其置为无效（
UPDATE refresh_tokens SET valid = false WHERE token = ?） - 避免在 Beego 的
Controller里做 refresh 逻辑，应封装为独立 service，确保事务一致性 - 更稳妥的做法：放弃 refresh 机制，改用“登录态续期”——每次合法请求都重签一个新 access token 返回给前端，前端自动覆盖本地存储（需配合
HttpOnly: false的前端管理）
真正难的不是写对那几行 jwt.NewWithClaims()，而是让每个中间件、每个 controller 都信任同一个用户上下文，且这个上下文不被伪造、不被复用、不因并发错乱——Beego 的 ctx.Input.Data 是线程安全的，但你要亲手把它填对、用对、清对。
