位图是RBAC权限校验的性能关键，通过将权限映射为二进制位并用位运算替代数据库联查，实现CPU级毫秒判定；需用稳定枚举序号编排权限，配合预计算与缓存协同标准RBAC模型。

位图（Bitmap）在 RBAC 权限校验中不是“锦上添花”，而是解决高频、低延迟权限判断的关键底层手段。它把一组布尔型权限映射为一个整数的二进制位，用 与（&）、或（|）、异或（^）、取反（~） 等位运算代替数据库查询或循环遍历，让“用户是否有某权限”变成一次 CPU 级别的计算。

为什么用位图替代角色-权限表联查？

传统 RBAC 每次校验需查用户→角色→权限三张表，5层 JOIN 在高并发下易成瓶颈；而位图将用户全部权限压缩为 1 个整数（如 int64 可存 64 项权限），校验只需：

• 从缓存或内存中取出该用户的权限位图值（如 0b101100）
• 构造目标权限的掩码（如第 3 位权限 → 0b000100）
• 执行 bitmap & mask != 0 即可判定

权限编码与位图映射设计要点

关键不在“能不能位运算”，而在“怎么编排才不冲突、易维护”：

• 权限必须有唯一、稳定的序号（非自增 ID），推荐用枚举定义：
  PERM_ORDER_VIEW = 1 << 0 // 1
  PERM_ORDER_EDIT = 1 << 1 // 2
  PERM_USER_DELETE = 1 << 5 // 32
• 避免动态分配位序：上线后新增权限只能追加高位（如第 6 位起），不可重排，否则历史数据失效
• 单个整数不够用时，可用 uint64 数组分段管理（如低 64 位=基础权限，高 64 位=扩展权限）

位运算在复合权限场景中的实用技巧

真实业务不止是“有/无”，常需“包含全部”“至少一个”“排除某几项”：

• 同时拥有 A 和 B：(bitmap & (A | B)) == (A | B)
• 拥有 A 或 B 任一：(bitmap & (A | B)) != 0
• 有 A 但无 B：(bitmap & A) && !(bitmap & B)
• 排除敏感权限（如禁止导出）：允许权限集 = bitmap & ~EXPORT_MASK

与 RBAC 模型的协同落地方式

位图不是取代 RBAC，而是优化其性能瓶颈层：

• 后台仍用标准 RBAC 表维护角色-权限关系（保证可读性、可审计）
• 服务启动或角色变更时，触发“权限位图预计算”：遍历所有角色，将其权限集合成对应整数，写入 Redis Hash 或本地缓存
• 用户登录后，根据其角色列表查出对应位图值，存入 JWT payload 或线程局部变量（ThreadLocal）
• 拦截器/切面中直接取该值做位运算，全程无 DB 查询