Beego中能真正拦截登录请求的Filter阶段只有beego.BeforeRouter和beego.BeforeStatic：前者适用于API接口，可安全使用Param和RequestBody；后者是唯一能拦截/static/路径的时机，但需手动解析URL参数。
Beego 中哪些 Filter 阶段能真正拦截登录请求
不是所有 Filter 都能在登录校验中起作用。很多人把权限逻辑塞进 beforerouter 或 beforeexec，结果发现对 /static/xxx 路径完全不触发——因为 Beego 默认将静态资源路径（如 /static/）绕过路由匹配流程。
真正有效的拦截点只有两个：
-
beego.BeforeStatic：唯一能捕获/static/users/123/private/*这类路径的时机，但此时ctx.Input.Param(":id")为空，必须手动从 URL 解析 -
beego.BeforRouter：适用于 API 接口（如/api/v1/users），可安全使用ctx.Input.Param()和ctx.Input.RequestBody
别在 init() 里注册权限 Filter——位置错，等于没写。
如何避免每次请求都查数据库做 RBAC 校验
RBAC 权限判断若每次都查 role_permission 表，QPS 上百就会卡住。正确做法是启动时加载全部策略到内存，运行时只做 O(1) 查找。
关键操作包括：
- 权限表
permission只存code字段（如user:read、order:create），不存 URL 或 method - 在
main.go初始化阶段，用orm.Raw("SELECT ...").ValuesList(&list)一次性加载所有role_id → []string{code}映射，存进map[int][]string - Filter 中通过
ctx.Input.Session.Get("role_id")拿角色 ID，再查内存 map 判断是否含当前resource:action
注意：resource:action 必须标准化生成，比如 POST /api/v1/users → user:create，GET /api/v1/users/123 → user:read；别直接拿原始 URL 做 key。
JWT Token 校验该放在哪一层、怎么防重放
Token 校验不能只靠中间件解析，否则容易被绕过或重复使用。Beego 下推荐分两层处理：
- 第一层（
BeforRouter）：解析Authorization: Bearer xxx，用jwt.Parse()验签+过期时间，失败则ctx.Abort(401) - 第二层（Controller 的
Prepare()）：检查该 token 是否在 Redis 黑名单中（如登出后写入blacklist:xxx，TTL=token 剩余有效期），并校验iat时间戳是否早于上次刷新时间（防重放）
别把 token 存进数据库主表字段；应单独建 user_tokens 表或用 Redis 存 user_id → [token1, token2]，方便批量失效。
静态资源权限控制最容易漏掉的三个细节
/static/ 路径的权限控制是 Beego 权限体系中最容易翻车的部分，三个高频坑点：
- 正则匹配路径末尾必须加
/*，否则/static/users/123/private/abc.jpg不会命中/static/users/:id/private - 提取参数只能靠
regexp手动解析，ctx.Input.Param(":id")在BeforeStatic阶段永远为空 - 拒绝访问必须用
ctx.Abort(403, "Forbidden")，不能只return或panic，否则可能返回 200 + 空内容，前端无法感知错误
真实项目里，/static/ 下往往混着用户私有上传文件，这类路径一旦漏控，就是越权读取的高危入口。
