casbin在微服务中需配合中央存储、实时同步机制和上下文透传才能生效；直接使用文件或内存模式会导致策略不一致，必须用redis-adapter或带刷新机制的gorm-adapter，并通过网关注入用户身份、扩展domain字段实现跨服务权限隔离。
Casbin 本身不直接支持微服务架构下的权限分发与同步，必须配合外部存储、策略同步机制和请求上下文注入才能落地。纯内存模式或单实例配置在微服务中会立刻失效。
为什么不能直接用 casbin.NewEnforcer("model.conf", "policy.csv")？
微服务多实例部署时，每个服务进程都持有一份独立的内存策略副本。你在 A 实例上通过 enforcer.AddPolicy() 添加的规则，B 实例完全感知不到；策略变更无法广播，RBAC 关系一写就“丢”。
- 默认文件驱动（
"policy.csv"）只读取启动时快照，运行时修改不持久化到文件，其他实例更不会 reload - 即使换成数据库驱动（如
gorm-adapter），也仅解决“存储统一”，不解决“策略变更实时生效”——因为 Casbin 不主动轮询或监听 DB 变更 - 没有上下文透传机制时，网关鉴权通过了，但下游服务拿到的
userID或role可能为空或伪造
必须用支持实时同步的适配器 + 中央策略存储
选型核心是：存储可被所有服务访问 + 支持事件通知或短周期刷新。推荐组合：redis-adapter（带 TTL 和 Pub/Sub）或 gorm-adapter + 自动 refresh 策略缓存。
-
redis-adapter可利用 Redis 的PUBLISH/PSUBSCRIBE在策略变更时通知所有实例调用enforcer.LoadPolicy() - 若用 MySQL +
gorm-adapter，需在每次鉴权前加一层缓存检查（比如用time.Since(lastLoad)> 5s 才LoadPolicy()），否则性能崩盘 - 避免用
file-adapter或memory-adapter，它们在微服务里等于没做权限控制
如何把用户身份和资源动作正确喂给 enforcer.Enforce()？
微服务间调用链路中，原始请求的 userID、resource、action 很容易丢失或被篡改，必须在网关层标准化注入，并透传到下游。
- 网关（如 Kong / APISIX / 自研）应在 JWT 解析后，将
sub（用户 ID）、roles（角色列表）写入 gRPC Metadata 或 HTTP Header（如X-User-ID、X-Roles） - 下游服务从 context 或 header 中提取字段，构造
enforcer.Enforce(sub, domain, obj, act)四元组；注意domain字段要填服务名（如"order-service"），否则跨服务策略无法隔离 - 不要在业务代码里硬编码
"admin"或"user"——这些应来自 JWT 声明或中心用户服务，否则权限绕过风险极高
模型定义（model.conf）必须匹配微服务边界
RBAC 模型如果只写 [request_definition] 三元组（sub, obj, act），根本无法区分 “用户 A 能否删除订单服务里的订单” 和 “用户 A 能否删除用户服务里的头像” —— 这两个操作对象同名但域不同。
- 务必启用
domain：在[request_definition]中写成r = sub, dom, obj, act，并在[policy_definition]对应扩展 - 策略行示例：
p, role:admin, order-service, /v1/orders/:id, DELETE，其中order-service是 domain，用于路由到对应服务的策略集 - 避免用
keyMatch2或正则做路径匹配——它在高并发下 CPU 消耗陡增；优先用前缀匹配（keyMatch）或预定义资源名（如order:create）
真正难的不是写几行 enforcer.Enforce()，而是让所有服务实例对“谁能在哪个域干哪件事”达成一致认知——这要求策略存储、变更通知、上下文透传、模型分域四者严丝合缝。漏掉任意一环，权限系统就变成装饰品。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
