casbin.enforce()总返回false，主因是未调loadpolicy()、策略格式与模型定义不匹配、传参顺序与request_definition不一致；需显式加载策略、校验p/g行字段顺序、严格按sub/obj/act传参。
casbin.Enforce() 总返回 false，先查这三件事
这不是 Casbin 有问题，而是策略没真正进内存或参数错位。最常卡住的点就三个：
-
enforcer.LoadPolicy()没调——尤其用gorm-adapter时，初始化 adapter 后必须显式触发一次，否则内存里永远空； - 策略行格式和
rbac_model.conf中[policy_definition]不匹配，比如写了p, alice, /api/users, GET，但模型定义是p = sub, act, obj，顺序一错就静默失败； -
Enforce()传参顺序和[request_definition]不一致：标准 RBAC 是sub, obj, act，传成"alice", "GET", "/api/users"就直接不匹配。
顺手加一行：log.Printf("loaded policies: %+v", enforcer.GetPolicy())，比翻数据库快十倍。
路径通配失效？别直接传 r.URL.Path
HTTP 中间件里直接把原始路径塞进 Enforce()，基本等于放弃通配能力。/api/v1/users/123 和 /api/v1/users/456 是不同资源实例，但策略里写 /api/v1/users/* 默认不会生效——Casbin 默认用字符串全等，不是 glob 或 regex。
- 启用
keyMatch2函数：在rbac_model.conf的[matchers]区块写m = keyMatch2(r.obj, p.obj)； - 传入前做标准化：从路由变量中提取 ID，拼成语义化 resource，比如
"user:123"或"order:456:refund"，而不是/api/v1/users/123； - 避免 query string 干扰：
/api/v1/users?id=123和策略里的/api/v1/users不匹配，中间件里得先清理 URL 再传。
角色继承没生效？g 规则必须显式存进策略表
Casbin 不会自动扫描你的 user_roles 表并生成角色映射。它只认内存里或适配器加载进来的 g 行策略，比如 g, alice, admin。漏掉这条，Enforce("alice", "post", "write") 就永远找不到路径。
- 用
gorm-adapter时，确保数据库有casbin_rule表，且g类型策略存进v0(用户),v1(角色) 字段； - 用户分配新角色后，不能只调
enforcer.AddRoleForUser()（它只写内存），必须同步调enforcer.SavePolicy()或让 adapter 自动监听变更； - 如果角色有层级（admin → editor → viewer），每级继承关系都要单独存
g行，Casbin 不会递归推导。
微服务间权限不一致？别复用同一个 enforcer 实例
多个微服务共用一个全局 enforcer 实例，看似省事，实则埋雷：策略热更新时，A 服务刚 LoadPolicy()，B 服务还在用旧缓存；或者某服务误调 ClearPolicy()，全链路权限瞬间清零。
- 每个微服务应独立初始化自己的
enforcer，通过适配器各自加载所属域的策略（如按 service_name 过滤）； - 策略变更通知走事件总线（如 Kafka），各服务监听后触发本地
LoadFilteredPolicy()，而非全量 reload； - 跨服务调用鉴权时，resource 字段要带服务标识，比如
"svc-order:order:456"，避免权限规则互相污染。
动态权限最难的不是加载策略，而是让所有服务在毫秒级内看到一致的状态——这要求你把策略同步逻辑当成核心链路来设计，而不是附加功能。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
