先给结论
多站点权限按两个维度交叉划分：能管哪些站点（全部、指定、单个站点），能做什么操作（查看、编辑、发布、配置）。用角色把常见岗位打包，再给人分配角色，避免逐人授权、人人都是超级管理员。
两个维度
| 维度 | 常见取值 | 说明 |
|---|---|---|
| 站点范围 | 全部站点 / 指定几个站点 / 单个站点 | 控制数据可见边界，跨站点人员才给全部范围 |
| 操作类型 | 查看、编辑内容、发布、管理用户、系统配置 | 越靠近配置层，授权越收紧 |
两个维度相乘得到实际权限：比如"只看不改的单站点访客""能编辑能发布的指定站点编辑""掌握系统配置的极少数管理员"。先划清楚维度，再定角色，授权的条理会清晰很多，后续调整也只需改角色定义。
角色设计思路
- 按岗位建角色，而不是按人建角色：新人入职直接套用现有角色。
- 内容编辑：只在自己站点内写稿、存草稿，不带发布权。
- 审核发布：在约定站点内审核并发布，与编辑分岗制衡。
- 站点管理员：管理本站点栏目与用户，看不到其他站点数据。
- 系统管理员：掌握全局配置与账号，只留给极少数负责人。
几条授权原则
- 最小权限：只给完成本职工作所需的最小范围。
- 按需新增：出现新需求先补角色定义，再往角色里加权限。
- 人员变动先收权限：调岗或离职第一时间调整授权。
- 定期核对：每隔一段时间对照花名册清一遍账号与角色。
相关阅读：产品百科
常见问题
站点少的时候需要分这么细吗？
站点少可以合并角色，但"编辑与发布分离""配置权收紧"两条建议保留。规模扩大后再拆分角色，比出了问题再补权限代价小得多。
一个人管多个站点怎么授权？
给他对应站点范围的角色即可，不必给全部站点权限。范围字段就是为此设计的：按实际负责的站点勾选，权限随职责走。
误授权了怎么处理？
先收回权限再排查影响，不要先改数据。事后复盘授权流程，把这次的教训固化成角色定义或检查项，避免同类问题重复出现。
权限和操作日志有关系吗？
有。发布、配置这类关键操作配合日志留痕，才能追溯"谁在什么时候改了什么"。权限负责事前控制，日志负责事后追溯，两者配套使用。