Beego权限控制需卡准执行时机：静态资源用beego.BeforeStatic拦截并手动解析路径，API权限校验应在Filter末尾、Controller启动前完成，统一处理路径和方法，权限查询用Raw SQL或分步ORM+Limit，缓存用内存键值对。
Beego 本身不带 RBAC 或权限中间件，但它的 Filter 机制配合合理路径建模和缓存策略，能落地一套响应快、易维护的权限控制。关键不是堆功能，而是卡准执行时机、避开路由绕过陷阱、别让每次请求都查库。
静态资源权限必须用 beego.BeforeStatic
所有以 /static/ 开头的请求（比如 /static/users/123/private/report.pdf）根本不会触发 BeforeRouter 或 BeforeExec。你在 init() 里注册再多权限逻辑也没用。
- 唯一有效的拦截点是
beego.BeforeStatic，它在静态文件处理器接管前执行 - 注册时路径要带正则和通配符：
"/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 末尾标准化后再做
很多人把权限检查塞进 Prepare()，结果发现 ctx.Input.Param(":id") 还没解析，或 POST body 已被读过一次。真正安全的校验点，是在 Filter 执行完毕、Controller 启动前，且路径已清洗干净。
- 用
strings.TrimSuffix(ctx.Request.URL.Path, "/")统一去除末尾斜杠，避免/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 全局锁更轻量
最难的部分不是写校验逻辑，而是让整个流程在 3ms 内完成——路径提取不准、时机选错、缓存没设、SQL 写重了，任何一个环节都会让权限变成性能瓶颈。
