根本原因是三元组未对齐策略：act未映射为语义动作（如get→read）、obj未路径归一化（去尾斜杠/替换动态段）、模型未启用keymatch2，导致匹配失败。
为什么直接在 Gin 中间件里调用 enforcer.Enforce() 会漏判？
根本原因在于三元组不匹配：Casbin 的 Enforce() 依赖 sub（主体）、obj（资源路径）、act（动作）严格对齐策略数据，而多数人直接传 r.Request.Method 和 r.URL.Path，没做语义映射和路径归一化。
-
act必须映射为业务语义动作，例如map[string]string{"GET": "read", "POST": "create", "PUT": "update", "DELETE": "delete"}；硬写"GET"而策略存的是"read"，必然失败 -
obj必须标准化：用strings.TrimRight(r.URL.Path, "/")去除尾部斜杠；再用正则或路由参数提取替换动态段，如/api/users/123→/api/users/:id - 模型中
[matchers]必须用keyMatch2(r.obj, p.obj)，而非keyMatch—— 后者不支持:id或*.js这类通配，双斜杠、尾部斜杠、路径参数全会失配
RBAC 角色继承关系为什么重启就失效？
因为把 g 规则（如 g, editor, user）写死在内存里，没持久化到 Adapter。Casbin 加载策略时只从配置源（如数据库、CSV 文件）读取 p 行和 g 行，enforcer.AddGroupingPolicy() 只是临时添加，服务重启即丢。
- 使用
gorm-adapter时，角色继承必须插入casbin_rule表，且ptype = 'g'，例如：INSERT INTO casbin_rule (ptype, v0, v1) VALUES ('g', 'editor', 'user') - 初始化后务必调用
e.LoadPolicy()，否则新增的g行不会生效 - 调试时用
e.GetGroupingPolicy()查当前加载的继承链，比猜更可靠 - 避免 A→B→C→D 多层嵌套继承，策略计算耗时随深度指数增长；生产环境建议控制在 2 级以内
如何避免中间件里反复初始化 enforcer 导致性能浪费？
每次请求都调用 casbin.NewEnforcer(...) 会重复加载模型和策略，IO 和内存开销大，且可能引发并发竞争（尤其用文件适配器时）。正确做法是全局单例 + 懒加载或启动时预热。
- 在
init()或应用启动入口处初始化一次enforcer，例如：var Enforcer *casbin.Enforcer+func initCasbin() { ... Enforcer = e } - 若用
gorm-adapter，确保连接池已复用，不要在中间件里新建 adapter 实例 - 策略变更时，调用
Enforcer.LoadPolicy()主动刷新，而非重建 enforcer - JWT 解析出的
sub应该是角色 ID（如"role_admin"）或用户 ID（如"1001"），不是用户名或 token 字符串——后者无法与g规则匹配
超级用户（如 root）权限绕过为何不生效？
常见错误是模型中 [matchers] 写法有误，或者没把 "root" 当作 sub 传入。Casbin 的超级用户逻辑是硬编码在 matcher 表达式里的，必须显式写出 r.sub == "root" 并用 || 连接主判断逻辑。
- 正确 matcher 示例：
m = g(r.sub, p.sub) && keyMatch2(r.obj, p.obj) && regexMatch(r.act, p.act) || r.sub == "root" - 注意：这里
"root"是字符串字面量，不是变量；若 JWT 中角色字段叫role，需在中间件里提取后赋值给c.Set("sub", "root")，再传给Enforce() - 如果用了自定义 subject 结构（如
{ID: 1, Role: "admin"}），matcher 无法直接比对r.sub == "root"，必须提前解包成字符串再传
Enforce() 调用前完成，且必须与模型中 keyMatch2 和 regexMatch 的行为保持一致。任何一步脱节，都会导致“明明配了权限却 403”的静默失败。
