多租户场景下ABAC的核心约束是租户策略必须刚性隔离：请求四元组需含dom字段，matcher强制校验r.dom==p.dom，策略存储按tenant_id分片，属性类型与命名全局统一，避免跨租户越权。
多租户场景下 ABAC 的核心约束是什么
不是“能不能用 Casbin”，而是“怎么避免租户策略互相污染”。微服务里每个租户（tenant_id）必须成为策略匹配的刚性维度，否则 alice 在 t-123 有权限，可能意外获得 t-456 的资源访问权。
常见错误现象：策略没带租户字段，或 matcher 没校验租户上下文，导致跨域越权；或者把 tenant_id 当成普通资源属性硬编码进结构体，结果无法复用通用 matcher。
- 所有请求三元组必须扩展为四元组：
r = sub, obj, act, dom（dom即 domain/tenant_id） - 模型文件中必须声明
[request_definition]和[policy_definition]含dom -
matcher必须显式比较r.dom == p.dom，不能只靠p行隐含隔离 - 策略存储必须按
dom分片（如 PostgreSQL 表加tenant_id字段，或用 Casbin 的FilteredAdapter）
abac_model.conf 里 domain 和属性匹配怎么写才不翻车
很多人抄示例只写 m = r.sub == r.obj.Owner，一加租户就崩——因为 r.obj 是结构体实例，r.dom 是字符串，类型不一致没法直接比。正确做法是把租户信息下沉到资源和用户属性里，并在 matcher 中统一提取。
推荐写法（适配 Casbin v2/v3）：
立即学习“go语言免费学习笔记（深入）”；
[request_definition] r = sub, obj, act, dom [policy_definition] p = sub, obj, act, dom, eft [policy_effect] e = some(where (p.eft == allow)) [matchers] m = r.dom == p.dom && eval(p.rule)
其中 p.rule 是自定义函数（需注册），例如：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
func (e *Enforcer) initCustomFunctions() {
e.AddFunction("is_owner", func(args ...interface{}) (interface{}, error) {
sub, ok := args[0].(string)
if !ok { return false, nil }
obj, ok := args[1].(map[string]interface{})
if !ok { return false, nil }
return sub == obj["owner_id"] && obj["tenant_id"] == args[2], nil
})
}
对应策略行：p, alice, data1, read, t-123, allow, is_owner(r.sub, r.obj, r.dom)
- 绝对避免在 matcher 里写
r.obj.tenant_id == r.dom——r.obj默认是 string，不是 map - 如果资源对象是 struct，必须用
adapter将其序列化为 map 或 JSON 字符串再传入 -
dom字段名必须全模型统一，Casbin 不允许 request 和 policy 定义不同名
Casbin Enforcer 如何按租户实例化才不耗内存
一个 Enforcer 实例不能混用多租户策略，但为每个租户 new 一个又太重。真实生产环境用的是“共享模型 + 租户级策略过滤”模式，不是 per-tenant Enforcer。
关键操作：
- 全局只初始化一个
Enforcer，模型固定加载一次 - 策略加载时用
LoadFilteredPolicy，传入domainFilter（如&DomainFilter{Domains: []string{"t-123"}}） - 每次请求前调用
e.LoadFilteredPolicy(filter)切换当前租户策略（注意并发安全，建议搭配sync.Pool缓存 filter 实例） - 禁用
e.EnableAutoSave(false)，避免策略变更自动刷所有租户
如果你用 GORM Adapter，filter 就是 WHERE 条件：WHERE tenant_id = ?，不是内存拷贝。
ABAC 属性设计最容易被忽略的三个硬伤
策略跑得通 ≠ 权限逻辑可靠。很多团队 ABAC 上线后出现“规则生效但语义错乱”，问题全出在属性建模阶段。
-
user.role写成"admin"而不是"role:admin"—— 后续加"role:auditor@t-123"就无法用keyMatch匹配 -
resource.tenant_id存成 int 类型，而请求里的r.dom是 string —— matcher 里==比较永远 false - 环境属性如
env.time由 handler 自己取time.Now()，导致测试时时间不可控、灰度发布时节点时钟偏差引发策略漂移
真正稳定的 ABAC 不靠语法炫技，靠属性字段的类型一致性、命名收敛、注入入口唯一。这些细节没对齐，matcher 写得再复杂也只是空中楼阁。
