casbin权限控制需策略加载、模型定义、请求映射三者对齐，否则易漏判或误拦；enforce参数必须严格匹配model.conf中[request_definition]顺序与语义，sub为字符串且与策略一致，obj需剔除路由前缀，act建议统一小写并映射。
直接用 Casbin，别自己手写角色判断逻辑——它不是“加个中间件就能跑”，而是需要策略加载、模型定义、请求上下文映射三者对齐，否则权限会漏判或误拦。
casbin.Enforce(sub, obj, act) 三个参数怎么填才不翻车
这是最常出错的一环：参数语义错位导致权限永远过不了。关键不是“能不能调通”，而是“传进去的值是否和策略库里定义的格式一致”。
-
sub（主体）必须是字符串，且和策略表里的sub字段完全一致；常见错误是传了int或带前缀的 ID，比如strconv.Itoa(int(waitUse.AuthorityId))是对的，但fmt.Sprintf("role_%d", waitUse.AuthorityId)就可能匹配不上策略 -
obj（资源）要剔除路由前缀，比如 API 是/api/v1/users，而策略里存的是/users，那就得用strings.TrimPrefix(c.Request.URL.Path, "/api/v1")，否则匹配失败 -
act（动作）建议统一转小写，因为GET和get在策略里算两个不同动作；如果策略定义的是read/write，那就不能直接传c.Request.Method，得做映射：map[string]string{"GET": "read", "POST": "write", "DELETE": "delete"}
gin 中间件里如何安全获取用户角色 ID
不能依赖 session 或 cookie 做角色判定，尤其在 JWT 场景下，角色信息应从 token payload 解析，而不是查数据库每次请求都打一次 DB。
- JWT 解析后，确保
AuthorityId字段存在且非空，否则sub会是空字符串，Casbin默认放行空主体（取决于模型配置，但多数 RBAC 模型不设空 sub 策略） - 避免在中间件里调
models.DB.Where(...).Find()查角色——这会拖慢所有接口，且破坏无状态设计；角色 ID 必须随 token 下发，并在GetClaims时一并解出 - 超级管理员（
is_super == 1）需单独 bypass：在Enforce前加判断，if waitUse.IsSuper == 1 { c.Next(); return }，否则 Casbin 规则再全也绕不过去
策略数据从哪来？不要硬编码 model.conf
Casbin 的模型文件（model.conf）只定义语法结构，真正起作用的是策略数据（policy），它必须动态加载，否则改个权限就得重启服务。
- 策略应存在数据库（如
casbin_rule表），用gorm-adapter加载；不要用file-adapter，那只是本地调试用的 - 初始化时调
casbin.NewEnforcer("model.conf", adapter)后，立刻执行e.LoadPolicy()，否则第一次请求会因策略为空而全部拒绝 - 前端修改角色权限时，后端必须调
e.RemoveFilteredPolicy+e.AddPolicy同步更新内存策略，不然下次请求还是旧规则
RBAC 真正难的不是“怎么让某个按钮消失”，而是策略变更时的原子性与一致性——比如批量删权限，中途失败会导致策略库和数据库不一致；这类边界情况，比中间件写法更值得花时间压测。
