enforce()总是false主因是模型/策略未加载成功，需先调用fmt.println(e.getpolicy())验证；常见原因包括rbac_model.conf含bom头、rbac_policy.csv有空行或注释、参数顺序与[request_definition]不一致。
enforce() 总是 false？先查模型和策略是否真加载成功
不是代码写错了，而是 Casbin 根本没读到策略。调用 e.Enforce() 前加一行 fmt.Println(e.GetPolicy())，输出为空就说明加载失败。
常见静默失败原因：
-
rbac_model.conf被 Windows 记事本保存，带 BOM 头——Casbin 不报错，直接跳过整文件 -
rbac_policy.csv里有空行或以#开头的注释行——Casbin 当作无效策略丢弃，也不提示 -
[request_definition]定义为r.sub, r.obj, r.act，但调用时写了e.Enforce("/api/users/123", "alice", "GET")，顺序错一位就恒 false 或 panic
RESTful 路径匹配失效？必须显式启用 keyMatch2
默认模型用 r.obj == p.obj 字符串全等，/api/v1/users/123 永远不匹配 /api/v1/users/*。
要支持通配符，三件事缺一不可：
- 在
rbac_model.conf的[matchers]段写：matcher = eval(keyMatch2(r.obj, p.obj)) - 确保用的是
github.com/casbin/casbin/v2或更高版本（v1不含keyMatch2） - 策略文件中写：
p, admin, /api/v1/users/*, GET，而不是具体路径
keyMatch2 只处理单星号 *，不支持 ** 或正则；要更灵活得换 keyMatch3 或自定义函数。
线上热更新权限后部分请求仍 403？别用 AddPolicy() 直接写内存
e.AddPolicy() 只写入内存策略表，但 Casbin 默认启用缓存，旧 goroutine 还在用老 cache 结果；e.LoadPolicy() 会清空全量策略再重载，高并发下可能短暂“全员无权限”。
正确做法是用命名策略操作：
e.AddNamedPolicy("p", "alice", "/data", "read")e.RemoveNamedPolicy("p", "alice", "/data", "write")
它们只修改指定策略行，不 reload 全量，也不污染缓存。真正难的不是第一次跑通 e.Enforce()，而是确保每次变更后，所有 goroutine 看到的都是同一份最新视图——这正是 Casbin 内置锁和原子操作要解决的，别绕开它自己搞 map + sync.RWMutex。
微服务间鉴权要不要复用同一套 Casbin 实例？
不要。每个微服务应独立初始化 Enforcer，但策略源可统一（如用 gorm-adapter 或 redis-adapter）。
关键点：
- 服务启动时调
e.LoadPolicy()加载全量策略，避免首次请求延迟 - 若策略存在跨服务共享需求（如全局 admin 角色），需在策略设计时显式支持 domain（即多租户模型），并在
Enforce()中传入第四个参数domain - JWT 中解析出
service_id后，应作为sub传入，而非拼进obj或硬编码判断
最易被忽略的是：策略变更通知机制。数据库改了策略，各服务实例不会自动感知——要么加轮询 e.LoadPolicy()，要么用 Redis Pub/Sub 主动推送 reload 信号，否则就会出现“配置已改，但部分实例仍走旧规则”的现象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
