Q86: 如何设计权限系统？
核心结论
权限系统不是“给用户贴几个角色标签”，而是把“谁能对什么对象执行什么操作”表达清楚，并且能被服务端稳定验证。
真正需要先想清楚的是：
- 权限作用于哪些资源
- 权限是角色级、对象级还是上下文级
- 谁负责做最终校验
- 高风险操作如何审计
如果这些边界不清晰，权限系统很快就会变成零散的 if 判断集合。
一、先分清权限控制的对象
常见对象包括：
- 玩家自己的角色数据
- 后台管理能力
- GM 操作
- 公会、队伍、拍卖等组织或共享资源
这些对象的权限模型差别很大，不适合一刀切。
二、角色模型只是起点，不是全部
RBAC 很常见，但在游戏里通常还不够。
因为很多权限不是“你是不是 GM”这么简单，而是：
- 你是不是当前公会会长
- 你是不是这封邮件的接收者
- 你是不是这个对象的拥有者
也就是说，很多权限是对象上下文相关的。
三、服务端必须做最终鉴权
客户端展示层可以决定按钮是否可点，但不能作为最终权限判断。
服务端至少要确认：
- 调用者身份
- 操作目标
- 当前上下文是否合法
否则越权只需要绕过客户端界面即可。
四、高风险操作需要额外约束
例如：
- 封号
- 发奖
- 改资产
- 批量执行命令
这类操作通常应具备：
- 最小权限
- 双重确认或更严格审批
- 审计日志
否则后台误操作的风险会非常高。
五、权限系统要和审计系统一起设计
权限不是只看“能不能做”，还要看“做了之后能不能追溯”。
更稳妥的做法通常是记录：
- 谁执行的
- 对谁执行
- 执行了什么
- 何时执行
- 是否成功
这样权限系统才能真正承担治理职责。
六、工程上更稳妥的组织方式
常见做法是：
- 身份认证系统确认“你是谁”
- 权限系统判断“你能做什么”
- 资源层判断“你对这个对象是否有权”
- 审计系统记录“你实际做了什么”
这四层不要混在一起。
七、常见误区
1. 权限系统就是 RBAC
RBAC 很常见，但对象级和上下文级权限在游戏里同样重要。
2. 前端把按钮隐藏了就算没权限
不对。最终校验必须在服务端。
3. 只有后台系统才需要权限设计
公会、队伍、交易、共享资源同样有权限边界。
参考资料
- RBAC、ABAC 和高风险操作审计实践资料