在权限规划中有一种十分共同且有意思计划叫位掩码权限规划，它在应对一些局部数据权限（权限点不多）的场景下，十分的犀利，比方 PingCode 常识办理页面权限就结合 ACL 对特定人群（用户、用户组、部分）做权限分配，最近做的一个低代码项目中的某块事务也体现很突出，屡次尝到甜头共享给大家
什么是位掩码权限？
维基百科搜了一下没有正式对位掩码权限的解说，还得是 ChatGPT：
位掩码权限（Bitmask Permissions）是一种权限办理体系，用于在核算机体系中对资源或操作进行操控和限制。它运用二进制位来表明不同的权限或访问级别。每个二进制位都代表一种权限或操作，能够设置为敞开或封闭。
了解过 Linux 权限的应该知道它的一些权限点：r（read 读）、w（write 写）、x（execute 履行），对应的权限值是 4、2、1。
这是一个标准的位掩码权限规划，其中 1、2、4 对应着依据“位”的二进制，拿 4 位举例： 1 => 0001 ， 2 => 0010 ， 4 => 0100 。
几个名词的小常识：
- mask 掩码，常表明权限，Worktile 中出现过
- x 的全称是 execute，之所以用这个字母表明，起源于 Unix 的规划哲学…… 简略的字母 x 更简洁、可读性高，表明最小单元，最根本的操作。后续业界许多也选用这种方法，我说一种大家就知道了 Lodash 运用回调函数第一个参数
_.map(arr, x=> x.name);
常见权限处理
1. 赋予多种权限
选用累计权限点的方法，比方具有“读”+“写”，4 + 2 = 6，那么终究权限值是 6，具有“读”+“写”+“履行”，那权限值是：4 + 2 + 1 = 7，以此类推，依据场景调配权限点即可。
2. 判别是否具有某种权限
运用位运算 &，比方现已具有的权限值是 3，想知道是否有可见（读）权限，那么就履行 !!(3 & 2)成果是 true，3 & 2 成果是 2，& 的思路是把 10 进制转换成 2 进制比较，二进制”与“的规则是同为 1 则为 1，否则为 0，和 2 的指数相与，成果必定只要两种成果：0 或 自身，把二进制的核算成果再转回 10 进制，0 代表无权限，权限点代表有此权限，更详细的二进制核算能够点这里。
判别只具有一种权限，全等比较即可，比方只读（除读之外没有其他权限）inputPermission === 4 ，假如权限值是列表或字符串的状况还需求做排他处理，很是费事。
3. 页面展现权限点
页面如何展现这些权限点以及映射也是值得思考的问题，不过在这种权限模式下就比较灵活了，由于权限值是一个数字而非数组或字符串，数组和字符串前后端是必须都要映射索引的，必然会有一套核算权限的逻辑，对于数字来说，是一个无序的，前端装备静态固定方位，映射方法就运用上述的与运算一行代码即可。
优缺陷
总的来说，位掩码在局部权限规划的场景下比较突出（权限点少且相互之间依赖性低）：
- 简略易用，设置、修改、校验、展现时十分便利
- 贮存效率高，尤其是在联系型数据库贮存结构有限时
- 权限点组合灵活性高，比方读+写、读+删除、履行+写……
可是它不合适权限点多，粒度细的体系，位就不够用了（第 10 个权限点已经是 1024 了）
实践使用
需求界面是这样的：
对应填写表单是这样的：
选型
选用哪门技术/手段，必然要考虑各种因素（事务场景、已有架构、易用、质量、功能），这里简略介绍一些前置条件：
- 低代码场景，主体表（是一个笼统节点，后续简称事务主体）是动态表，动态字段
- 联系型数据库（选用的原因是这块事务框架指定了 MySQL）
- 权限粒度是字段，且权限点有限
- 权限绑定的用户主体（成员/部分/安排人物/使用人物/职位）散布于不同的表
针对于上述条件能够得出的定论就是本文讲的 位掩码权限的规划计划， 其实中间环节是能够有许多思考的（不感兴趣的能够越过） 一些定论：
- 联系型数据库，权限值不引荐是列表（目标、数组），一是不支持，存 json 串也比较膈应，最好 用根本数据类型（字符串、数字）
- 权限绑定的用户主体散布多表，需求 排除相关表的计划，选用相关字段的方法 ，假如选用相关表计划有以下弊端：
- 散布于多个主体相关权限表，缺陷是 表涣散，成本高 ，在动态表的状况下额外在创立动态表也很费力，后续依据不同主体找不同的表。
- 散布于一张表存多个主体映射权限的数据，缺陷是主体（这里是装备的模块）数量不固定，比较 容易形成数据量大 ，总数是：事务主体数据量 * 用户主体数量 * 权限点数量，所以后续还要 考虑分表 。
- 无论上面哪种都需求 额外多查一次相关表
- 权限值的贮存假如是 01 拼接的字符串（0 代表无权限，1 代表有权限），那么需求考虑权限值的展现以及单字段校验等方法，由于字符串一个字符映射一个权限点，所以前端展现时需求知道哪一位对应什么权限，这种状况下前后端都必然要有一个 权限点索引装备，还得有一套依据索引匹配的逻辑 。
选用位掩码权限的方法有这些优势：
- 数字作为根本数据类型， 在任何数据库都支持 ，而数组或 JSON 需求 NoSQL 类的数据库支撑。
- 数字比较列表或字符串更简略， 不用考虑权限点映射顺序的相关装备和核算程序 。
- 数字比较相关列表更简略 ，减少查表次数，内聚性高（与事务主体绑定更近） ， 更节省内存 （主要是字段和表之间的比照）
- 权限值用数字更简洁，在多层嵌套的 JSON 下，显然 数字比目标或数组更清楚 。
permissions: {
read: true,
write: true,
require: true
}
// good
permissions: 7
最后
还是重复两点吧：
- 权限点小于 6 个，选用此计划十分合适，否则不要运用。
- 用户主体类型复杂的状况能够结合 ACL 或 RBAC 混合运用。
最后提供能够直接运用的代码片段：
- 定义权限点
- 验证工具函数
- HTML 中便利的管道
