应全局复用单个 casbin enforcer 实例，在 main.go 初始化并调用 loadpolicy() 验证加载成功；路径需标准化，策略字段顺序与模型严格一致；启用 enablelog(true) 调试匹配过程，策略变更后须显式 savepolicy() 持久化。
Beego 项目里初始化 Casbin Enforcer 的正确姿势
别在每个请求里 NewEnforcer()，也别把模型和策略加载逻辑塞进 controller。全局复用一个 enforcer 实例是安全且必要的，否则策略不同步、内存浪费、并发下判断结果可能错乱。
推荐做法：在 main.go 或 app.conf 初始化后，调用一次 enforcer.LoadPolicy()，再用 enforcer.GetPolicy() 打印几条验证是否真加载成功——很多人跳过这步，结果策略文件明明存在却始终返回 false。
- 模型路径必须可读（如
conf/rbac_model.conf），且内容语法合法； - 适配器若用
beego-orm-adapter，注意它默认建表名是casbin_rule，字段顺序必须与模型中[request_definition]和[policy_definition]严格一致； - 如果模型写的是
r = sub, act, obj，那后续所有Enforce()调用就必须是enforcer.Enforce("alice", "read", "/data")，顺序错一位就永远不匹配。
Beego 中间件里提取 request 参数的常见陷阱
Beego 的 Controller.Ctx.Input.URI() 或 Controller.Ctx.Request.URL.Path 返回的路径可能带前缀（如 /v1/api/users/123），但策略里存的却是 /api/users 或 /users。不 normalize 就直接传给 Enforce()，会导致路径字面量不等、匹配失败。
- 建议统一截掉版本号或 base path，例如用
strings.TrimPrefix(path, "/v1")； - 资源名若来自数据库目录 ID（如
dir_id=789），不要拼接原始 URL 路径，应提前查出对应资源标识符（如"dir:789"）再传入； - 避免在中间件里反复调用
GetRolesForUser()+GetPermissionsForUser()手动拼权限——Casbin 的 RBAC 自动继承已涵盖该逻辑，直接Enforce(sub, obj, act)即可。
用 beego-orm-adapter 时必须改的三处代码
官方 beego-orm-adapter 在较新 Beego 版本（v2+）下会因 ORM 接口变更而 panic，或清空已有策略表。这不是配置问题，是适配器本身没适配新版 beego/orm 的 InsertMulti 和事务行为。
- 修改
adapter.go中LoadPolicy()方法，显式指定字段映射，防止因 struct tag 或列顺序错位导致读取为空； - 重写
SavePolicy()，禁用自动清空表逻辑（原实现含o.Raw("TRUNCATE ...").Exec()）； - 确保
casbin_rule表中p_type字段值为"p"（策略）或"g"（角色继承），不能是空字符串或"P"（大小写敏感）。
调试 Enforce() 返回 false 却找不到原因？开日志 + 检查 matcher
enforcer.EnableLog(true) 是最直接的调试手段，它会输出每次 Enforce() 调用的完整匹配过程：哪些策略被遍历、matcher 表达式求值结果、最终 effect 是什么。比断点更可靠，尤其在并发请求中。
- 重点看日志里是否出现
no policy matched—— 那说明策略根本没加载，或字段顺序/值不匹配； - 如果看到多条
policy matched but effect is deny，检查模型中[policy_effect]是否写成e = some(where (p.eft == deny))（即黑名单模式），而你实际想用白名单； - matcher 里用了
keyMatch但没导入函数：需在模型开头加import "m" "github.com/casbin/casbin/v3/util/keymatch"，否则/api/users/*这类规则不会生效。
最易被忽略的是：策略变更后，AddPolicy() 或 AddGroupingPolicy() 只改内存，不自动落库。必须显式调用 enforcer.SavePolicy()，否则重启服务就丢权限。这个动作在 Beego 的 FinishRouter 钩子或事务提交后做更稳妥。
