权限设计模型哪个最好用？对比RBAC和ABAC的优缺点。

话说回来，干我们这行，权限系统这玩意儿是绕不过去的坎儿。以前我那套老系统，就是简单的“你是管理员吗？”或者“你是普通用户吗？”然后一堆 if else 写死在代码里。那叫一个难维护！

产品经理屁大点需求一改，我就得跟着改一堆代码。实在受不了了，新项目我决定自己动手，彻底重构一套权限体系。我这人嘛要搞就搞得清清楚楚。

我的实践：是从哪里开始的？

一开始就两个选择摆在我面前：RBAC（基于角色的那个，老外叫Role-Based Access Control）和ABAC（基于属性的那个，叫Attribute-Based Access Control）。

我先去拉了几个资料看。RBAC看起来最简单，就是把人分成几拨，比如老板、主管、普通员工，然后给每拨人分配权限。这多好理解，PM也能懂。我快速搭了一个RBAC的架子。

• RBAC的优点就是：结构简单，上手飞快，配置起来像搭积木。
• 缺点很快也暴露了：一旦业务复杂点，比如“A部门的主管只能看A部门的数据，不能看B部门的”。如果用纯RBAC，我就得造出“A部门主管”、“B部门主管”这些角色，权限稍微变动一下我就得新建一堆角色。我光是想想就头皮发麻，这不就是角色爆炸了吗？

实在受不了角色的爆炸式增长，我又把目光转向了ABAC。这玩意儿可就厉害了。它是靠“属性”来判断权限，比如“如果用户是主管，并且他所在部门和资源所在部门一样，并且操作是只读，就放行”。

我花了好几天时间去琢磨，这简直就是把权限规则写成一堆逻辑判断。确实强大，理论上任何复杂的权限都能实现。但是：

• ABAC的缺点：太难搞懂了！部署复杂，性能也打问号。最要命的是，要是有一天我离职了，下一个人根本看不懂我写的是什么鬼东西。而且让PM来配置规则，那画面太美我不敢看，指不定哪天出个BUG自己都不知道。

最终拍板：我选择的路子

一番折腾后，我得出了一个结论：纯粹追求“最好用”的模型，往往会陷入困境。得看你的业务和团队能力！

我们那个Wares Management System，功能权限（比如谁能点“删除”按钮）是比较固定的，用RBAC管得妥妥的。但数据权限（比如张三只能看自己区域的销售单）却很灵活，这是RBAC的痛点。

所以我采取了一个折中的办法，也是我目前用着最顺手的：

我保留了RBAC的主体框架，用来管理功能菜单和按钮这种粗粒度的权限。这是骨架，是给PM看的配置界面。

然后，我偷偷摸摸在数据查询层面，加了一层简单的属性判断。比如，给用户或者角色多加一个“数据范围”的属性（全国、华东、自己部门）。当他查询数据时，我就去查一下这个属性，然后默默地给他的SQL语句或者API请求加上一个过滤条件。

这不就实现了大部分ABAC想要干的“数据权限”了吗？而且不复杂，就多了个属性字段和后台的过滤代码。完全没有引入复杂的规则引擎。

现在回过头来看，这个“RBAC主体 + 简单属性过滤”的混搭方式，简直是省心省力。

它保留了RBAC那种简单配置、容易理解的优点，同时又解决了纯RBAC搞不定数据权限的痛点。后期的维护工作量，起码给我少了一半。实践证明，够用、稳定，能让PM和自己都舒服的，就是最好用的！