大概使用讲解
这里用 1.例子基本单位 里面的例子作为讲解
@ 具体的使用到的方法（api）去查文档，这里就给个例子说明他是个什么东西，有什么作用
你自己保存数据（比如存储在表中的基本数据），然后定义 model（策略规则，里面告诉casbin 怎么判断是否可访问的条件），根据你定义的model，把基本数据的所有关系都存下来（一般都存着一个表内，用对应功能前缀+主键id作为内容），然后就可以使用casbin 的方法来判断是否可访问
区别：
原生表的方式：要保存五个基本单位的相互之间的关系，需要四个数据库的实际表来保存，然后每次判断是否有权限，就要去查询出关系，然后判断这个用户对应的角色是否有该资源的访问权限
casbin方式：将所有关系都存在一起（靠自己维护），然后获取用户的基本信息，用户信息，资源信息，直接调用 casbin 方法判断即可，不用考虑他们之间的关系和查询，因为这一步就是 casbin 做了
总的来说：
casbin 就是让你把怎么判断的规则定好，然后把数据单位的关系都给他，他根据你给的规则，根据你传入的参数（用户，被访问的资源等基本参数），反馈给你true ，fasle
1.例子基本单位（所有单位带域的标识）
一种五种，租户为特殊，用来划分数据区域，没有就代表所有数据都在一起
用户，部门，角色，资源（api等被访问的，也可称为规则），租户（也可以称为域）
这些数据存储在数据库表中
2 基本单位的关系（如果有域，所有关系带域的标识）以及 策略存储关系
2.1 四种关系
用户部门关系，
部门角色关系，
用户角色关系，
角色资源关系
2.2概述
关系都存储在一张表中（load 的时候都加载进来），其他数据都对应单独表（用户，部门，权限等等，这里只是把关系都合在一起）
关系数据全都存在一张关系表中，用来给casbin 加载到police 中
2.3 两种数据格式( _id 表示对应表的主键id)
第一种每个基本单位之间的关系，g 开头表示基本单位的关系类型，也对应了model 的 role_definition
(g,u_id,d_id,t_id) 用户（user）和部门（dept）在租户（ten）下的关系
(g,u_id,r_id,t_id)用户（user）和角色（role）在租户（ten）下的关系
(g,d_id,r_id,t_id)部门（dept）和角色（role）在租户（ten）下的关系
第二种角色对应的功能关系,p 开头表示功能关系,也对应了model 的 policy_definition
(p,r_id,t_id,rule_id,all) 角色（role）在租户（ten）下有资源（rule）的所有关系
3.使用模式 adapter 适配器模式（自定义存储和取数据逻辑）
实现(adapter persist.Adapter)内的五个 方法（相当于把对应的police 的操作，同步到数据库的增删改查中）,具体的逻辑自己定义
比如 LoadPolicy 方法加载所有的关系数据到内存中，SavePolicy 方法插入一条关系数据等等
// Adapter is the interface for Casbin adapters.
type Adapter interface {
// LoadPolicy loads all policy rules from the storage.
LoadPolicy(model model.Model) error
// SavePolicy saves all policy rules to the storage.
SavePolicy(model model.Model) error
// AddPolicy adds a policy rule to the storage.
// This is part of the Auto-Save feature.
AddPolicy(sec string, ptype string, rule []string) error
// RemovePolicy removes a policy rule from the storage.
// This is part of the Auto-Save feature.
RemovePolicy(sec string, ptype string, rule []string) error
// RemoveFilteredPolicy removes policy rules that match the filter from the storage.
// This is part of the Auto-Save feature.
RemoveFilteredPolicy(sec string, ptype string, fieldIndex int, fieldValues ...string) error
}
4.model 定义
[request_definition]
r = sub, dom, obj, act
[policy_definition]
p = sub, dom, obj, act
[role_definition]
g = _, _, _
[policy_effect]
e = some(where (p.eft == allow))
[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act
5.使用过程
每次使用，都新建对应对象 Enforcer 对调用 LoadPolicy 该方法，比如（casbin.NewSyncedEnforcer）
LoadPolicy 中获取所有关系，加载到内存中，然后传入需要比较的数据（这里的例子就是，用户id，资源id，判断该用户是否能请求该资源）调用 Enforcer 比较即可
6.功能细化，ALL 权限约束
提供的 Casbin 模型和策略中，"ALL" 通常用作一个通配符或特殊标记，用来表示“所有”或“任意”的操作或条件。具体来说：
代表所有操作：
在你给出的示例中，ALL 可能表示所有的操作（act），即角色对某个资源的所有可能操作都是被允许的。这意味着，不论是读取、写入、删除等操作，都被允许。
简化策略管理：
使用 ALL 可以简化策略的定义。如果不使用 ALL，你可能需要为每种具体的操作（如 read、write、delete 等）分别定义策略，这样会增加策略的数量和复杂度。通过使用 ALL，你可以用一条策略来覆盖所有操作。
为什么需要 ALL
灵活性：在某些场景下，你可能希望某个角色对某个资源的所有操作都被允许，而不必分别定义每种操作的策略。这时，ALL 就能提供这种灵活性。
减少策略数量：使用 ALL 可以减少你需要定义的策略数量，使管理更为简便。
如果要细化访问权限，就将 all 对应 改成 读(read)写(write)，执行(op)等等,然后在执行判断的方法Enforcer 的时候，参数对应传入，查看它是否有对应权限，比如 原来是 用户 18 在租户 11下是否有资源45的ALL权限
enforcer.Enforce(u_18,t_11,rule_45, "ALL")
如果细化，可以变成
enforcer.Enforce(u_18,t_11,rule_45, "WRITE")
细化成：用户 18 在租户 11下是否有资源45的写权限
前后不同在于，只不过记录的时候，关系中要记录多条，比如，读写各一条，操作，复制各一条等等，有多条关系数据，这个例子 ALL 是简化了，实际逻辑在自己的业务中自己处理
