Go中struct嵌套无法表达角色继承关系，因其仅为字段方法复制，不支持动态权限叠加、运行时增删角色及继承链追溯；需用map+递归构建rolePermissions与roleInheritance映射表，并防环检测。
为什么直接嵌套 struct 无法正确表达角色继承关系
Go 没有传统 OOP 的类继承机制，用 struct 嵌套（比如 type Admin struct{ User }）只能复制字段和方法，但权限逻辑是动态的：一个用户可能同时属于 Editor 和 Reviewer，而 Reviewer 又隐含 Reader 权限。硬编码嵌套会绑定死继承路径，无法运行时组合或撤销。
真正需要的是「权限可叠加、可查询、可追溯来源」——这意味着得把角色当作标签（tag），把继承关系抽成独立映射表。
- 权限判断必须查
role → permissions映射，而不是依赖 struct 层级 - 角色 A 继承角色 B，应表现为
inheritanceMap["A"] = []string{"B"}，而非字段嵌套 - 递归解析继承链时要防环（比如 A→B→A），需加访问标记或深度限制
如何用 map + 递归构建可继承的角色权限树
核心是两个数据结构：rolePermissions 存每个角色的直接权限（如 "editor": {"post:write", "comment:delete"}），roleInheritance 存继承关系（如 "admin": {"editor", "reviewer"}）。查权限时，从目标角色出发，递归展开所有父角色，合并权限集合。
示例关键逻辑：
func (r *RBAC) GetPermissions(role string) map[string]bool {
seen := make(map[string]bool)
result := make(map[string]bool)
var dfs func(string)
dfs = func(rl string) {
if seen[rl] {
return // 防环
}
seen[rl] = true
for _, p := range r.rolePermissions[rl] {
result[p] = true
}
for _, parent := range r.roleInheritance[rl] {
dfs(parent)
}
}
dfs(role)
return result
}
- 每次调用
GetPermissions都做一次 DFS，适合权限变更不频繁的场景；高频校验建议预计算并缓存结果 -
roleInheritance必须是无向图的反向边（即子→父），不能存成父→子，否则递归起点错位 - 空角色（如
""或不存在的 role）应返回空 map，避免 panic，调用方自行处理默认权限
如何让用户拥有多个角色并支持运行时增删
用户不是绑定单个角色，而是持有角色名列表（[]string），比如 user.Roles = []string{"editor", "reviewer"}。权限校验时，遍历所有角色，合并各自展开后的权限集。
增删角色必须同步影响权限缓存（如果用了缓存），且不能破坏继承链完整性：
- 添加角色前，先用
GetPermissions(newRole)验证该角色是否存在，避免静默失败 - 删除角色后，若用户角色列表为空，应显式赋予基础角色（如
"guest"），而不是留空 - 禁止在运行时修改
roleInheritance映射（如roleInheritance["admin"] = append(...)），必须用线程安全的写操作（如sync.RWMutex包裹）
为什么用字符串切片存权限比自定义 type 更实用
权限标识如 "user:read"、"post:publish" 是典型的资源+动作二元组，用 string 直接表示最灵活：支持通配符匹配（"post:*"）、日志打印清晰、序列化到 JSON/DB 无额外开销。若定义 type Permission string，虽能加方法，但实际中极少需要封装逻辑——权限校验本质是字符串集合运算。
- 用
map[string]bool而非[]string存权限集合，避免重复插入和O(n)查找 - 通配符支持需额外解析（如
strings.HasPrefix(p, "post:") || p == "post:*"），不要试图在GetPermissions里自动展开"*"，那会污染权限语义 - 权限字符串应全小写、用英文冒号分隔，避免大小写混淆或特殊字符导致解析错误
