for user in editors: assign(user, "editor") // 5 次分配每人一次分配即获得 查看/编辑/发布 整组；策略条数 = 1 条角色定义 + 5 条分配。新增第 6 个编辑只再分配一次；要加「审核」能力，只改 editor 定义，6 人同时生效。
数据与服务 · 账号与安全
角色Role
角色是一组权限的命名打包：分配角色等于整组授权，检查问「这个角色里含权限 X 吗」，移除角色则整组收回——不用逐条勾、逐条删。
分配一个角色，整组权限一次到位
角色把权限命名打包。先在这一台选成员、选角色、分配，看权限 chips 整组点亮；再检查「能否 X」看 ALLOW/DENY 落在请求卡；最后切「直接 per-user」对比策略条数爆炸。操作过一遍，再读后面的命名。
角色把一组权限命名打包。分配角色 = 整组授权；检查问「这个用户的角色里含权限 X 吗」； 移除角色 = 整组收回。切到「直接 per-user」对照不用角色的代价。
角色定义（每个角色 = 一组权限）
成员（选中后看下方当前权限）
阿明 的当前权限策略 +0 条
查看编辑发布删除
RBAC：这些 chips 是上方角色分配的整组结果——分配/移除一个角色，chips 整组翻转。
检查「这个角色 / 用户含权限 X 吗」
还没检查；选好成员和权限，点「检查」看 ALLOW/DENY 落在这张请求卡上。
原因：阿明还没有角色，所以没有任何权限。下一步：保持选中阿明、选中 editor，点「分配角色」把 查看/编辑/发布 这一整组一次授给他。对照：切到「直接 per-user」模式，就得逐条勾这三条。
提示：唯一的红色按钮是「分配角色」；检查、移除、重置与分段按钮全走中性。重点对照——分配后 chips 整组点亮、移除后整组熄灭、切「直接 per-user」看「策略条数」翻倍。
角色台暴露的五条 RBAC 规则
面板已经把每条规则演给你看了，这里把它们命名清楚，并补上无法直接操作的部分。
- 角色 = 一组权限的命名包，不是单条权限：上方角色定义区里，editor 一次打包 查看/编辑/发布，admin 再多打包 删除。新增一项能力时改角色定义，所有持有该角色的人同时生效——不必逐个用户改。
- 分配角色 = 批量授权，移除 = 批量收回：服务端记的是「用户 → 角色」一条，结果却是整组权限翻转。这正是 RBAC 比直接 per-user 授权省事的地方：到岗分配一次、调岗换一个角色、离职移除一次。
- 授权检查 = 「这个角色里含权限 X 吗」：请求卡上的 ALLOW/DENY 就是这条查询的结果。检查只读角色声明，不会顺手放出声明里没有的权限；身份是不是你由 auth 判，role 只判能不能。
- 不用角色的代价：策略爆炸 / 角色污染：切到「直接 per-user」，策略条数 = 每人每权限一条，人一多就漏勾错勾。反过来，角色拆得太细、一人顶十几个角色（角色污染）同样难管——通常用少量稳定岗位角色 + 偶尔按需的例外，而不是给每个人拼一个独有角色。
- 身份每请求怎么带角色过来，交给 session/token：服务端不会每次都查数据库读角色，而是登录时把角色声明（claims）写进 session 或 token，后续请求靠它判定。改角色后要让旧声明失效或刷新——这层生命周期在 session/token 卡片讲，这里只把角色当作声明的内容。
什么时候用角色，什么时候不用
从「同岗位的人权限是否一致、要不要批量收放」出发，而不是默认都堆角色。
- 用角色：权限能按岗位稳定归类（编辑、审核、只读、管理员），同岗位的人权限一致，需要批量授予与收回、可审计谁有何角色。
- 不用角色，直接判单条权限：权限很少（就一两条）、或权限高度个体化（每人不同），强行套角色反而制造只有一个用户的「独有角色」。
- 混合：岗位级能力用角色批量给；个别资源级例外（这个文档只给某人编辑）用 permission 单条叠加。先角色兜底，再单条补缺。
- 不要做的：给每个用户拼独有角色、把互斥权限塞进同一角色、改角色后不刷新旧声明导致撤销延迟。
从定义到检查：RBAC 最短路径
只走这几步，每步都改变服务端可验证的状态。
- 列出全部能力（查看/编辑/发布/删除…），按岗位打包成少数稳定角色；角色定义本身入库，不写死在前端。
- 给用户分配角色（
user → role）；登录时把角色声明写进 session 或 token，作为后续请求的凭据内容。 - 每个受保护动作检查
user.role.permissions.includes(action)，命中放行、否则 403；前端按钮隐藏只是体验优化，不能替代服务端检查。 - 改角色（调岗）或移除角色（离职）后，刷新或撤销旧 session/token 声明；审计日志记录谁授予、何时变更、何时生效。
同一目标「给 5 个编辑同样的权限」：分配角色，还是逐条勾
只改一处——授予权限的方式——后续维护差很多。这是 RBAC 最该记住的一条。
for user in editors: grant(user, "view","edit","publish") // 15 条策略每人 3 条、5 人共 15 条策略；第 6 人到位要再勾 3 次，漏勾一条就少权限、错勾一条就越权。加「审核」能力要逐人改 6 次，没有角色这层抽象，维护成本随人数线性涨。
快速自测
团队从 3 人扩到 30 人、每人都是编辑级权限。用角色和直接 per-user 授权，策略条数和后续加人成本差在哪？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。