B 端平台权限体系设计：RBAC 模型的技术实现逻辑编辑导语：这篇文章基于 B 端平台的权限体系设计，细致地阐述了作者对于RBAC 模型的理解，并向我们展示了 RBAC 模型的具体应用和逻辑实现过程。感兴趣的话就一起看一下吧。 在以往多个 0~1 大型数字中台项目中，底层权限体系是我最关怀的，也要求产品经理和开发同学、尤其是后端开发必须熟悉后方可进入产品开发项目。 RBAC 模型给了 B 端产品非常容易理解的权限方法，平台中也有很多 RBAC 相关的文章介绍。本篇重点介绍实际的技术实现过程，供大家参考，方便 B 端产品经理与开发同学的沟通，避开走弯路（曾经 3 个项目在此处折损颇多）。一、权限体系的基础介绍 权限体系的要素有：业务组织、角色、用户和权限、页面、视图。组织、角色、用户是基于业务变化可即时调整的。权限是最底层属性，由开发人员基于业务需求开发实现。权限约束的对象是后台的具体实例。根据数据接口安全需要，可设计专用的接口权限。权限分功能权限（含菜单权限）、组织权限、数据权限。页面、视图是系统根据业务配置、给对应用户呈现的内容。 详细的权限体系说明，可参考 《成熟 CRM 系统的权限体系解析》 一文。二、对 RBAC 模型的深度理解 RBAC（基于角色的权限控制）模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地给予用户权限（如下图），从而达到用户和权限解耦的目的。 RBAC 模型强调了用户、角色、权限间的关系，但在 B 端业务应用中是不能脱离业务部门存在的，因此 4 者必须建立关系。除了以上 4 张表外，后台还需记录用户、业务部门、角色的关系表，如下图： 1. 成熟业务平台中对业务记录的基础要求 成熟 ERP、CRM 平台中权限体系非常严密，对业务记录有严格的要求：即单条业务记录中必须有业务记录的 Owner 和 Owner 所属的业务部门。因此，业务记录必须有 7 个基本字段：创建人、创建时间、最后修改人、最后修改时间、Owner、Owner 所在的业务部门+状态（启用/停用），当 Owner 发生变化时，Owner 所在的业务部门同步更新。 只有如此，才能保障组织权限的严格控制，其实现逻辑：根据当前用户所在的组织和角色的数据范围来从数据记录中的 Owner 所在的业务组织来猎取的。加载可见数据后，再根据当前用户的编辑等权限进行前端的功能按钮控制。 举例：张三是销售经理，查...
