casbin 的 enforce 总返回 false 最常见原因是策略未加载成功、请求参数与策略字符串不精确匹配（大小写/路径前缀/空格等），或 jwt 未解析出角色就直接传入。
为什么 Casbin 的 Enforce 总返回 false？
最常见原因是策略没加载成功，或请求的 sub/obj/act 和策略规则对不上。Casbin 不自动猜你的业务语义——它严格按字符串匹配，大小写、前缀斜杠、空格全算数。
- 检查
enforcer.LoadPolicy()是否执行成功，加日志确认enforcer.GetPolicy()返回非空切片 -
Enforce("alice", "/api/users", "GET")和策略p, alice, /users, GET不匹配：路径不一致，少了个/api - 若用 RBAC 模型，确保
addRoleForUser("alice", "admin")在Enforce前调用，且角色权限已通过addPolicy定义 - 模型文件（如
rbac_model.conf）必须用enforcer.InitWithFile(model.conf, policy.csv)加载，不能只传字符串内容
Gin 中间件里怎么安全传用户和路由信息给 Enforce？
Gin 的上下文生命周期短，别在中间件外缓存 *gin.Context 或从中取值后延迟调用 Enforce——用户身份可能还没解析完，或路由已被重写。
- 在中间件内部直接提取：用
c.GetString("user_id")（前提是鉴权中间件已写入），或c.Request.URL.Path+c.Request.Method - 避免硬编码路径前缀，用
c.FullPath()获取注册路由模板（如/api/v1/users/:id），再配合自定义函数做通配映射 - 不要在
Enforce前修改c.Request.URL.Path，Casbin 不读 Gin 的路由树，只认你传进去的原始字符串 - 性能敏感时，把
enforcer设为全局变量（注意并发安全：Casbin v2+ 的Enforcer是 goroutine-safe 的）
数据库策略（PostgreSQL/MySQL）热更新失效怎么办？
用 casbin-pg-adapter 或 gorm-adapter 时，LoadPolicy 只在启动时执行一次；改了 DB 里的策略，内存不会自动同步。
- 手动触发刷新：在策略变更后调用
enforcer.LoadPolicy()，但注意高并发下可能引发短暂不一致 - 更稳的做法是监听数据库变更（如 PostgreSQL 的 LISTEN/NOTIFY），收到信号再 reload，避免轮询
- 如果用
AutoSave(false)，记得每次改策略后显式调用enforcer.SavePolicy()，否则 DB 写入但内存不更新 - 注意适配器的
filteredPolicy支持程度：不是所有 adapter 都实现LoadFilteredPolicy，查文档确认
如何让 Casbin 认出 JWT 用户角色而不是原始 token 字符串？
Casbin 不解析 JWT——它只收三个字符串参数。所谓“基于角色”，是你自己把 JWT 解析后的 role 字段传给 Enforce，不是 Casbin 自动从 token 里抽。
立即学习“go语言免费学习笔记（深入）”；
- 解析 JWT 后，取
claims["role"]或claims["groups"]，转成字符串传给Enforce(role, path, method) - 策略文件里写
p, admin, /api/*, POST，不是p, "admin", ...—— Casbin 不处理引号，引号会变成字面量的一部分 - 若前端传的是 user ID，后端需先查 DB 或缓存拿到其角色，再喂给
Enforce；跳过这步就会拿 ID 当角色用，策略永远不匹配 - 调试时打印
fmt.Printf("sub=%q, obj=%q, act=%q", sub, obj, act)，比看日志更准——字符串不可见字符（如 BOM、换行）常在这里露馅
策略加载时机、字符串精确匹配、JWT 到角色的转换链路，这三个地方出问题的概率加起来占八成。其他都是配置细节，先盯牢这三处。
