## 访问权限（RBAC）

用于把“谁能做什么”变成可实现、可测试、可审计的权限模型，避免权限只写成一句话导致实现分散且口径不一致。

适用场景：
- 多角色系统（运营/审核/财务/合规/管理员/外部协作方）
- 需要到页面按钮、接口、操作动作粒度的权限控制

核心要素：
- 角色（Role）：一组权限的集合（例如派车员、司机、财务、管理员）
- 权限点（Permission）：可授权的最小动作（例如 `order:approve`、`dispatch:revoke`）
- 资源（Resource）：权限作用对象（页面、接口、功能、菜单、数据实体）
- 操作（Action）：对资源的动作（read/create/update/delete/approve/export）

RBAC 表格格式（建议直接写进各功能的 `rbac.md`）：

角色表：
| 角色 | 职责/边界 | 典型操作 | 备注 |
|---|---|---|---|
| Admin | ... | ... | ... |

权限点表（权限点为前后端统一口径）：
| 权限点 Key | 名称 | 资源类型 | 资源路径 | Action | 说明 | 关联接口 | UI 控制点 |
|---|---|---|---|---|---|---|---|
| order:approve | 审批订单 | Page/Button | /orders/{id}#approve | approve | ... | POST /api/orders/{id}/approve | 订单详情页-审批按钮 |

角色-权限矩阵（允许/禁止/条件允许）：
| 权限点 Key | Admin | Reviewer | Operator | 条件说明（如数据范围/状态） |
|---|---|---|---|---|
| order:approve | 允许 | 允许 | 禁止 | 仅状态=待审批；仅本组织数据 |

落地建议：
- 前后端统一以权限点为口径：UI 控制和后端鉴权都基于同一权限点，禁止只做前端隐藏或只靠后端报错。
- 把权限与场景/用例绑定：在场景中标注触发者角色；验收用例至少覆盖“允许/拒绝/提示文案/无权限默认落点”。
- 默认拒绝：未在矩阵中明确允许的，一律按禁止处理，并要求给出一致的错误码与提示文案。
- 条件允许必须可执行：把“条件”落成可实现字段（数据范围、组织/租户、状态、所有者、时间窗），避免只写自然语言。
