必须用1ULL，因页表权限位操作需64位无符号整型确保高位正确置位，避免int溢出或未定义行为。
权限位定义必须用 1ULL 避免整型溢出
直接写 1 在 32 位系统或 <code>int 上会触发未定义行为，尤其当权限位超过 31 时。C++ 默认字面量是 int，左移超界即 UB，编译器可能优化掉判断逻辑，导致权限校验静默失效。
正确做法是显式使用无符号长整型字面量：
constexpr uint64_t PERM_READ = 1ULL << 0; constexpr uint64_t PERM_WRITE = 1ULL << 1; constexpr uint64_t PERM_DELETE = 1ULL << 32; // 安全，支持到第 63 位
- 所有权限常量统一用
uint64_t类型别名（如using perm_t = uint64_t;），避免混用int/unsigned/long long - 禁止用宏定义（
#define PERM_READ (1 ），宏不参与类型检查，也无法被 <code>constexpr上下文安全使用 - 若需运行时动态添加权限位（如插件系统），应限制最大位数 ≤ 63，并做
if (bit >= 64) throw std::invalid_argument("bit out of range");
has_permission(perm_t mask, perm_t flag) 必须用按位与而非相等判断
常见错误是写成 mask == flag 或 mask & flag == flag —— 后者因运算符优先级问题实际等价于 (mask & flag) == flag，看似对，但当 flag 是复合权限（如 PERM_READ | PERM_WRITE）时，该表达式要求 mask 必须「恰好包含且仅包含」这些位，无法表达「至少拥有」语义。
真正需要的是子集判断：只要 mask 中对应 flag 的每一位都为 1 即可：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
constexpr bool has_permission(perm_t mask, perm_t flag) noexcept {
return (mask & flag) == flag;
}
- 这个函数只做「是否具备某组权限」判断，不是「是否仅有这些权限」
- 若需检查「是否仅含指定权限」（如白名单模式），才用
mask == flag；但生产环境极少这么用，容易误拒合法组合 - 注意
flag为 0 时，(mask & 0) == 0恒真 —— 这符合直觉：「拥有空权限」总是成立的，但业务上应禁止传入 0 作为有效 flag，建议加断言assert(flag != 0);
用户权限存储推荐用 std::bitset<64> 而非裸 uint64_t
裸 uint64_t 虽省内存、位运算快，但缺失边界检查、可读性差、调试困难。比如打印一个权限值 0x15，你得手动换算成二进制再对照表查是哪几位；而 std::bitset 支持直接输出字符串、遍历置位索引、甚至流输入输出。
关键优势在开发期和运维期：
std::bitset<64> user_perms; user_perms.set(PERM_READ); // 可读 user_perms.set(PERM_WRITE); // 可写 std::cout << user_perms << "\n"; // 输出 000...00011，一目了然
-
std::bitset的set()/test()/reset()成员函数比手写|=/&/&=~更不易出错，尤其配合命名常量时 - 64 位足够覆盖绝大多数场景；若需扩展，可用
std::vector<bool>或自定义大位集，但要接受性能折损 - 序列化时仍可快速转为
to_ullong()存数据库，反序列化时用std::bitset(str)构造，不破坏现有存储格式
权限继承与组合必须用按位或，但要注意「拒绝权限」的特殊处理
角色继承（如「管理员」拥有「编辑者」+「审核者」权限）天然适合 | 运算。但真实系统常需「拒绝某权限」（例如某子部门禁用删除），此时单靠位掩码无法表达「拒绝」语义 —— 位运算是纯正交的，没有否定维度。
简单方案是引入两层掩码：allow_mask 和 deny_mask，最终有效权限为 (allow_mask & ~deny_mask)：
perm_t effective = (role_allow | user_allow) & ~(role_deny | user_deny);
if (!has_permission(effective, needed)) { /* 拒绝 */ }
- 拒绝权限优先级高于允许权限，这是最小惊讶原则；
~deny_mask确保任意被 deny 的位无论是否在 allow 中都被清零 - 禁止把 deny 权限也塞进同一个整数里用负数或高位表示 —— 这会让位逻辑混乱，且
has_permission()函数无法复用 - 如果业务中「拒绝」极少，可改用白名单模式：只存 allow_mask，所有未显式允许的权限默认拒绝，此时无需 deny_mask，但需确保初始化时权限全为 0
位掩码权限本身不难，难的是在多角色、多层级、带拒绝规则的场景下保持逻辑可推演。最常被忽略的是：权限变更后未同步更新缓存中的 bitset 值，或序列化时用了 to_ulong() 却没处理溢出异常——这会导致部分高位权限永远无法生效。
