Beego中AuthFilter提取resource:action需清洗路径并规范method：用ctx.Request.URL.Path（非URL/URI）、ReplaceAll("//","/")、TrimSuffix("/"),ToUpper()方法，避免匹配失败。
Beego 本身不内置 RBAC，但用好 Filter + 路径标准化 + 合理表结构，比硬塞 Casbin 更稳、易调试、贴合生命周期。
AuthFilter 里怎么提取准确的 resource:action
权限校验失败的第一原因，从来不是 SQL 写错，而是 ctx.Request.URL.Path 没清理干净，导致匹配不上数据库里的 permission.code。
- 必须用
ctx.Request.URL.Path（不是ctx.Input.URL()或ctx.Input.URI()），它才返回原始路径，不含查询参数 - 手动清理：
strings.ReplaceAll(path, "//", "/")合并重复斜杠，strings.TrimSuffix(path, "/")统一去尾部斜杠 -
ctx.Request.Method是大小写敏感的，务必strings.ToUpper()，否则"get"和"GET"会被当成两个动作 - 有 API 版本前缀（如
/v1/users）的，建议在 Filter 里提前strings.TrimPrefix(path, "/v1")，避免权限表里堆满带版本号的冗余记录 - 别用
ctx.Input.Param(":id")——Prepare()阶段路由参数还没解析，此时取出来永远是空字符串
ROLE_PERMISSION 表为什么不能只存 role_id 和 permission_id
只存两个 ID 的关联表，会把权限锁死在“能/不能访问某接口”这一层，后续加按钮级、数据行级控制时，要么改表结构，要么堆 if-else 硬编码。
- 真正可扩展的结构必须包含：
resource字段（业务资源标识，如"user"、"order"，不是完整 URL） -
action字段（操作类型，如"create"、"export"，不限于 CRUD） -
method字段（显式绑定 HTTP 方法，避免GET /users/:id和DELETE /users/:id共用一条权限带来的歧义） - 这样一条记录就明确表示：“角色 A 可用
POST方法对user资源执行create操作”。新增/reports/export接口？只需插入resource="report",action="export",method="GET"一条记录，不用动代码
Beego 里要不要集成 Casbin
关键不是“能不能用 Casbin”，而是“要不要为它引入额外配置、存储依赖和匹配开销”。
立即学习“go语言免费学习笔记（深入）”；
-
Casbin适合策略频繁变更或需 ABAC 扩展的场景；而多数后台系统权限规则稳定、路径结构清晰，自己实现反而更轻量 - 很多项目在
AuthFilter里查一次缓存就返回结果，QPS 轻松扛住 5k+；而Casbin每次Enforce()都要走模型匹配 + 策略遍历，没做本地缓存时容易成瓶颈 - 如果真要用
Casbin，注意GetPermissionsForUser()不会自动继承角色权限，得先调GetRolesForUser()，再循环查每个角色的权限——这点常被忽略，导致权限漏判
最易被忽略的其实是路径清洗和 method 大小写处理：一个没 trim 尾部斜杠，一个没转大写，整个权限链就断了。线上排查时，90% 的“权限失效”问题都卡在这两步。
