第1章：RMC授权模型的核心设计
大家好，我是你们这堂课的老朋友。今天咱们聊聊RMC授权模型。说实话，权限管理这块我踩过不少坑，尤其是早期做企业级应用时，权限设计一塌糊涂，后来重构了三次才稳定下来。嗯，今天就把这些经验掰开揉碎了讲给你听。
1.1 权限粒度设计：到底要细到什么程度？
权限粒度，说白了就是「你能管多细」。我见过不少系统，权限只到「菜单级」——你有权访问某个页面，但页面里的按钮、数据字段全都能看。这其实很危险。
我个人习惯把权限粒度分成三层：
- 粗粒度：菜单、页面级别的访问权限。比如「能否进入用户管理页面」。
- 中粒度：操作级别的权限。比如「能否新增用户」、「能否删除用户」。
- 细粒度：数据字段级别的权限。比如「能否查看用户的手机号」、「能否修改用户的薪资字段」。
你想想看，如果只做粗粒度，一个普通员工进了后台，可能连老板的工资条都能看到。这合理吗？显然不合理。
核心原则：权限粒度越细，安全性越高，但管理复杂度也越高。建议从业务风险出发，只对敏感操作做细粒度控制。
我在项目中遇到过这样一个场景：一个HR系统，普通HR只能查看员工的基本信息，但高级HR可以查看薪资和绩效。如果只做菜单级权限，那就得给普通HR和高级HR各做一个页面，维护成本极高。用细粒度权限，一个页面就够了，后端根据权限动态控制字段显示。
1.2 权限继承机制：别让管理员累死
权限继承，说白了就是「子节点自动拥有父节点的权限」。为什么要做继承？因为手动给每个用户分配权限，管理员会疯掉的。
举个例子：一个公司有「销售部」→「华东销售组」→「上海销售组」这样的组织架构。如果给「销售部」分配了「查看客户列表」的权限，那么「华东销售组」和「上海销售组」应该自动继承这个权限。
RMC中的权限继承模型是这样的：
// 权限继承伪代码
class PermissionNode {
String id;
String parentId;
List<String> permissions; // 当前节点权限
List<String> effectivePermissions; // 实际生效权限（含继承）
void calculateEffectivePermissions() {
if (parentId == null) {
effectivePermissions = permissions;
} else {
PermissionNode parent = findParent(parentId);
parent.calculateEffectivePermissions();
effectivePermissions = new ArrayList<>(parent.effectivePermissions);
effectivePermissions.addAll(permissions);
}
}
}这里有个坑：继承不能无限叠加。我曾经见过一个系统，权限继承链长达10层，每次查询权限都要递归10次，性能惨不忍睹。我的建议是：继承层级控制在3层以内，超过3层就用扁平化设计。
注意：权限继承虽然方便，但也要防止「权限泛滥」。如果一个节点继承了太多权限，反而失去了细粒度控制的意义。
1.3 权限冲突解决策略：当两个规则打架时
权限冲突，说白了就是「一个用户同时属于两个角色，一个角色允许，一个角色禁止，到底听谁的？」
我遇到过最典型的场景：用户A既是「普通员工」角色（禁止删除数据），又是「系统管理员」角色（允许删除数据）。这时候如果系统处理不好，要么普通员工误删了数据，要么管理员干不了活。
RMC中常用的冲突解决策略有四种：
| 策略名称 | 规则 | 适用场景 |
|---|---|---|
| 拒绝优先 | 只要有一个角色拒绝，就拒绝 | 安全要求极高的系统 |
| 允许优先 | 只要有一个角色允许，就允许 | 需要灵活授权的系统 |
| 优先级排序 | 给角色设定优先级，高优先级说了算 | 角色层级分明的系统 |
| 显式覆盖 | 用户级别的权限覆盖角色级别的权限 | 需要个性化授权的系统 |
我个人习惯用「拒绝优先 + 显式覆盖」的组合。为什么？因为安全第一。如果某个操作被明确拒绝了，那就不能执行，除非管理员显式给这个用户开了绿灯。这样既保证了安全性，又保留了灵活性。
小技巧：在实现冲突解决时，建议用「权限矩阵」来可视化。把用户、角色、操作画成一个表格，一眼就能看出哪里有冲突。
1.4 最小权限原则在RMC中的实现
最小权限原则，说白了就是「给用户刚刚好的权限，不多给一分」。这个原则说起来简单，做起来难。
我记得有一次做金融系统，开发人员为了省事，给所有用户都分配了「超级管理员」角色。结果一个实习生不小心删除了整个客户数据库...嗯，从那以后我再也不敢忽视最小权限原则了。
在RMC中实现最小权限原则，我建议分三步走：
- 角色定义阶段：先列出所有可能的操作，然后按「职责」分组。比如「查看订单」和「修改订单」应该分到不同角色里。
- 权限分配阶段：给每个角色分配「刚好够用」的权限。不要因为方便就多给。
- 定期审计阶段：每季度检查一次，看看有没有用户权限「膨胀」了。
这里有个实用工具：权限基线。你可以定义一个「最小权限基线」，所有角色的权限都不能低于这个基线。比如：所有用户都必须有「修改自己密码」的权限，但「查看他人密码」的权限绝对不能给。
// 最小权限基线示例
{
"basePermissions": [
"user:changeOwnPassword",
"user:viewOwnProfile",
"system:logout"
],
"forbiddenPermissions": [
"user:viewOtherPassword",
"system:deleteAllData"
]
}核心思想：最小权限不是「越少越好」，而是「刚刚好」。少了影响工作，多了带来风险。
知识体系总览
下面这张图是我自己画的RMC授权模型核心逻辑，你看一眼就能明白整体结构：
这张图把RMC授权模型的四个核心机制串起来了。你看，用户关联角色，角色绑定权限，权限控制资源。而权限粒度、继承、冲突解决、最小权限这四个机制，就是保证这个链条不出问题的关键。
好了，这一章的内容就到这里。记住：权限设计没有银弹，关键是根据业务场景灵活组合这些机制。下一章我们会深入讲角色管理的实战技巧，到时候见。
公众号:蓝海资料掘金营，微信deep3321