1、权限管理基础：为什么需要权限管理？RBAC模型核心概念

说实话，我刚入行那会儿，对权限管理这事挺不以为然的。

那时候做个小项目，用户就几十号人。谁有什么权限，直接在代码里写死几个 if-else 就搞定了。简单粗暴，跑得也挺欢。

直到有一次，一个实习生误操作，把一个内部管理接口暴露到了公网。结果呢？有人直接绕过了前端页面，用 curl 调接口删了整张用户表。那天晚上，我们全团队陪着 DBA 从备份里恢复数据，搞到凌晨三点。

嗯，从那以后，我再也不敢说「权限管理不重要」这种话了。

为什么需要权限管理？

你想想看，一个系统只要超过三个人用，就一定会出现「谁该看到什么、谁不该看到什么」的问题。

我见过太多项目，初期图省事，把权限写死在代码里。结果业务一扩张，需求一变，改权限比改业务逻辑还痛苦。说白了，权限管理不是「要不要」的问题，而是「什么时候开始做」的问题。

具体来说，权限管理解决三个核心问题：

• 数据安全——防止未授权的人看到不该看的数据。比如普通员工不该看到全公司的薪资表。
• 操作合规——确保只有特定角色才能执行敏感操作。比如只有财务主管才能审批报销单。
• 审计追溯——出了问题能查到是谁干的。没有权限控制，出了事连锅都甩不出去。

我记得有个客户，他们的系统被内部员工删了关键业务数据。因为没有权限日志，查了两个月都没找到是谁。最后只能全公司重设密码，搞得人心惶惶。这就是典型的「省了权限管理的功夫，赔了数据安全的钱」。

RBAC 模型：权限管理的行业标准

说到权限管理，就绕不开 RBAC（Role-Based Access Control，基于角色的访问控制）。

这个模型从 90 年代提出到现在，几乎成了权限管理的「通用语言」。为什么它能活这么久？因为它足够简单，又足够灵活。

RBAC 的三个核心概念

RBAC 模型就三个东西：用户、角色、权限。听起来简单，但很多人一开始就把它们搞混了。

概念	定义	举个例子
用户（User）	系统的操作者，通常是自然人	张三、李四、王五
角色（Role）	权限的集合，代表一类职责	管理员、编辑、访客
权限（Permission）	对某个资源的操作许可	创建文章、删除用户、查看报表

它们之间的关系是这样的：

• 用户被赋予角色
• 角色拥有权限
• 用户通过角色间接获得权限

为什么要绕这么一圈？直接给用户分配权限不行吗？

行，但那是小项目。一旦用户数量超过 50 个，直接分配权限就是灾难。你想想，100 个用户，每人 10 个权限，那就是 1000 条关联记录。哪天要改一个通用权限，你得挨个改 100 个人的配置。累不累？

用角色做中间层，就简单多了。改角色的权限，所有拥有该角色的用户自动生效。这就是 RBAC 的精髓——解耦。

一张图看懂 RBAC 核心逻辑

下面这张图，是我做权限系统时最常用的结构图。它清晰地展示了用户、角色、权限三者之间的关系：

RBAC 的三种常见模型

RBAC 不是只有一种玩法。根据业务复杂度，它有几个变种。我按实际使用频率排个序：

1. RBAC0（基础模型）——就是上面说的用户-角色-权限三层结构。80% 的场景用这个就够了。
2. RBAC1（角色继承）——角色可以继承其他角色。比如「超级管理员」继承「普通管理员」的所有权限，再加一些额外权限。
3. RBAC2（角色约束）——加了互斥、基数等约束。比如一个人不能同时拥有「财务审核」和「财务审批」两个角色，防止自己审自己批。

一个简单的权限判断示例

说了这么多理论，来点实际的。下面是一个最简单的权限判断逻辑，用伪代码表示：

// 判断用户是否有删除文章的权限
function canDeleteArticle(userId, articleId) {
    // 1. 获取用户的所有角色
    roles = getRolesByUserId(userId)
    
    // 2. 获取这些角色拥有的所有权限
    permissions = getPermissionsByRoles(roles)
    
    // 3. 判断是否包含「删除文章」这个权限
    return permissions.contains('article:delete')
}

这段代码虽然简单，但它体现了 RBAC 的核心流程：用户 → 角色 → 权限 → 判断。

实际项目中，你肯定不会每次都查数据库。缓存、预加载、权限树……这些优化手段我们后面会详细讲。但底层逻辑，万变不离其宗。

小结

权限管理不是什么高深的技术，但它是一个系统的「地基」。地基没打好，上面盖再漂亮的房子也白搭。

RBAC 模型的核心就三个词：用户、角色、权限。记住它们之间的关系：用户通过角色获得权限。就这么简单。