Beego权限校验需分三环节精准控制：静态资源用beego.BeforeStatic正则解析路径并手动提取ID；API鉴权在Filter末尾、Controller启动前完成，标准化路径并用Raw SQL查权限；JWT必须显式指定算法并验证Issuer/Audience。
Beego 的权限校验不能靠“加个中间件”就完事——静态资源绕过路由、参数解析时机错乱、ORM 查询拖垮性能，三个环节任一出错，权限就形同虚设。
静态资源权限必须用 beego.BeforeStatic
所有以 /static/ 开头的请求（比如 /static/users/123/private/report.pdf）根本不会进 BeforeRouter 或 Prepare()，你在 init() 里注册再多 Filter 都没用。
- 唯一有效的拦截点是
beego.BeforeStatic，它在静态文件处理器接管前执行 - 注册时 pattern 要带通配符：
"/static/users/:id([0-9]+)/private/*"，末尾/*才能匹配子路径 -
ctx.Input.Param(":id")在BeforeStatic阶段不可靠，必须手动从ctx.Request.URL.Path提取并正则解析 - 会话读取用
ctx.Input.Session.Get("user_id")，拒绝访问统一走ctx.Abort(403, "Forbidden")
API 权限校验必须卡在 Filter 末尾、Controller 启动前
很多人把鉴权逻辑塞进 Prepare()，结果发现 ctx.Input.Param(":id") 还没解析，或者 POST body 已被读过一次导致后续 Controller 解析失败。
- 真正安全的校验点：Filter 执行完毕、Controller 尚未启动，且路径已标准化
- 统一去除末尾斜杠，避免
/users和/users/被当成两个资源 -
ctx.Request.Method是大小写敏感字符串，务必转成大写再比对 - 若有 API 版本前缀（如
/v1/users），建议在 Filter 中提前剥离，否则权限表里全是冗余规则 - 映射请求为
resource:action格式：比如GET /api/v1/users/:id→user:read，POST /api/v1/orders→order:create
权限查询别碰 ORM Join，Raw SQL 或分步查才是底线
Beego ORM 的 RelatedSel() 在 User → Role → Permission 多层关联下极易触发 N+1 查询或笛卡尔积，一次鉴权可能拉出 5~8 次 DB 请求。
- 推荐用
orm.Raw()写单条 SQL，只SELECT必需字段，WHERE条件限定在user_id和状态有效上 - 若坚持用 ORM，至少拆成两步：先查用户所有
role_id，再用In()查对应权限，不跨三张表Join - 务必加
.Limit(100)，防止单个管理员被赋予上百权限拖垮中间件 - 缓存用应用层内存即可，key 设为
"perm:uid_123"，TTL 5~10 分钟，比 Redis 全局锁更轻量
JWT 鉴权必须显式指定算法，jwt.Parse 是安全雷区
直接调用 jwt.Parse 会尝试用任意算法（如 HS256、none）解码，攻击者可篡改 Header 将 "alg": "none" 发起混淆攻击，导致验签跳过。
- 永远用
jwt.ParseWithClaims(tokenString, claims, func(*jwt.Token) (interface{}, error) { return []byte(secretKey), nil }) - 禁止在回调函数中动态返回密钥——易触发密钥泄露或类型转换 panic
- 若需支持
RS256，密钥必须是*rsa.PublicKey类型，且回调内部需判断token.Method.Alg()并返回对应公钥 - Token 应从
this.Ctx.Input.Header.Get("Authorization")提取，格式为"Bearer xxx"，用strings.TrimPrefix去掉前缀 - 验签失败时，
claims.Valid()只检查过期时间，还需手动验证claims.Issuer、claims.Audience是否匹配服务预期值
最难的部分不是写校验逻辑，而是让整个流程在 3ms 内完成——路径提取不准、时机选错、缓存没设、SQL 写重了，任何一个环节都会让权限变成性能瓶颈。
