enforce 总是返回 false 的主要原因是租户 id 未正确传递，casbin 默认只识别 sub、obj、act 三元组，需将租户 id 嵌入 obj（如 "tenant-a:order:123"）或扩展为四元组并自定义 matchfunc。
为什么 Enforce 总是返回 false？租户ID没传对
多租户场景下，Enforce 失败最常见原因不是策略写错，而是请求参数里缺了租户标识。Casbin 默认只认 sub、obj、act 三个位置，你得把租户 ID 塞进其中一个——通常塞进 obj 的前缀，或单独扩展为四元组（需自定义匹配函数）。否则所有策略都按“全局”跑，自然隔离不了。
实操建议：
- 统一约定：把租户 ID 作为
obj的第一段，比如"tenant-a:order:123"，策略里写p, user1, tenant-a:order:* , read - 避免用
sub存租户 ID——用户身份和租户归属应解耦，sub是用户 ID（如"u1001"），租户关系查role或缓存映射 - 若必须四参数校验（
sub, tenant, obj, act），得重写MatchFunc，且模型文件改用[request_definition]四字段声明
如何让 LoadPolicy 只加载当前租户的策略？
Casbin 默认从存储加载全部策略，租户一多就内存暴涨、校验变慢，还容易策略串租户。不能靠应用层过滤，得在加载时就切片。
关键点：
- 用支持条件查询的适配器，比如
gorm-adapter，调用adapter.LoadPolicyWithFilter(&casbin.Filter{V3: []string{"tenant-a"}}) - 数据库表必须有
tenant_id字段（casbin_rule表加列），且索引覆盖ptype, v3 - 别在内存里用
GetFilteredPolicy过滤——那只是从全量策略里筛，没解决加载膨胀问题 - 每次切换租户（如 HTTP 请求进来），要先
enforcer.ClearPolicy()再LoadPolicyWithFilter，否则旧策略残留
GetPermissionsForUser 返回了其他租户的数据？
这个函数默认不感知租户，它只按 sub 查 p 行，而你的策略如果漏了租户字段（比如写成 p, u1001, order:123, read 而不是 p, u1001, tenant-a:order:123, read），就会跨租户命中。
排查和修复：
- 检查策略数据：用
enforcer.GetPolicy()打印当前加载的策略，确认每条obj都带租户前缀 - 禁止手动拼 SQL 插入策略——必须走
enforcer.AddPermissionForUser("u1001", "tenant-a:order:*", "read")，让它自动按模型格式写入 - RBAC 场景下，
g行（角色继承）也要带租户，例如g, u1001, admin-tenant-a，而不是笼统的admin
HTTP 中间件里怎么安全传租户上下文？
租户 ID 通常从 JWT 或请求头（如 X-Tenant-ID）来，但中间件顺序错了会导致 enforcer 拿不到租户上下文，继而加载错策略或校验失效。
正确链路：
- 租户解析中间件必须在 Casbin 中间件之前，且把租户 ID 存到
context.Context，比如ctx = context.WithValue(r.Context(), "tenant_id", tid) - Casbin 中间件从
context取租户 ID，再调用enforcer.LoadPolicyWithFilter和enforcer.Enforce(...) - 别用全局变量存当前租户——Go 的 HTTP handler 是并发的，会相互覆盖
- 如果用了 Gin/Echo，优先用框架原生上下文（
c.GetString("tenant_id")），比手撸context.Value更可靠
租户策略加载和校验的边界很窄：策略加载时机、参数构造方式、上下文传递顺序，三者错一个，隔离就形同虚设。最容易被忽略的是策略存储层没按租户分片，导致删租户时误删别人策略——删之前务必加 WHERE tenant_id = ?。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
