Permission · 能不能做

Permission 的身份：module : resource : action [! state]

一条 Permission 就是一个「能不能做」的最小开关。它需要一个稳定、可读、可枚举的身份——一个 key。约定俗成的结构是三段（可选第四段）：Module（业务边界 / context / domain）·Resource（操作对象）·Action（动词），必要时再加 !State 把动作限制在某个状态下。

1 · key 的四段结构

能力清单是一份白名单：格式合法的组合未必已登记，未登记的 key 既不能分配，也不应被 server 接受。

图 1-1 · permission key 的四段拼装与能力清单校验。可点选各段，观察拼出的 key 是否落在清单内，以及它的风险等级与可配 scope。

注 · Action 不应简化成「读／写」两种，因为业务动作远不止 CRUD。一个订单的生命周期里有 submit → approve / reject → cancel → rollback → reopen → archive，每一步都是一条独立的「能不能做」。把它们拆成独立 action，才能精细授权：让运营能 approve 但不能 rollback。

2 · Action 的三类

表 2-1 · 本系列采用的 action 集合，按三类归纳。
类别	动作	说明
CRUD	`read / create / update / delete`	对象的基本增删改查
数据流	`import / export`	批量进出，常单独管控（导出 = 数据外泄风险）
业务流转	`submit / approve / reject / cancel / rollback / reopen / archive`	状态机上的转移，通常配 `!state`

注 · !State 把 action 限制在资源处于某个状态时才允许。例如 content:article:approve!submitted 表示「只能审批处于 submitted 的文章」——已发布或草稿状态的文章不在这条权限的范围内。状态门把权限和业务状态机衔接起来，是「能不能做」这一维里最细的一层。