64位整数（如uint64_t）恰好有64个二进制位，每位可表示“开/关”两种状态，因此最多支持64个互斥权限；超出需改用bitset或数组，且高位（如第63位）可用，只需用无符号类型（如1ULL）。
为什么64位整数刚好能存64个独立权限位
因为一个 uint64_t 有64个二进制位，每位可表示“开/关”两种状态，对应一个权限开关。不是“刚好够用”，而是“最多支持64个互斥权限”，超出就得换结构（比如 std::bitset 或数组）。
常见错误是误以为高位（如第63位）不能用——其实可以，只要用无符号类型，1ULL 是合法且安全的；用 <code>1 会触发未定义行为（有符号左移溢出）。
- 必须用
ULL后缀或显式static_cast<uint64_t>(1) 避免符号问题</uint64_t> - 权限位编号建议从 0 开始（对应
1ULL ），和数组索引、调试输出更一致 - 别把权限位和“用户ID”“角色ID”混在一起存——位域只管布尔态，数值型信息得另存
如何定义和组合多个权限常量
直接手写 1ULL 、<code>1ULL 容易出错且难维护。推荐用枚举 + <code>constexpr 或宏生成。
更稳妥的做法是定义命名常量：
立即学习“C++免费学习笔记（深入）”；
constexpr uint64_t PERM_READ = 1ULL << 0; constexpr uint64_t PERM_WRITE = 1ULL << 1; constexpr uint64_t PERM_DELETE = 1ULL << 2; constexpr uint64_t PERM_ADMIN = 1ULL << 63; // 最高特权位
组合权限用按位或：PERM_READ | PERM_WRITE；清权限用按位与非：perms & ~PERM_DELETE；判断是否拥有用按位与：(perms & PERM_ADMIN) != 0。
- 避免用
enum class直接隐式转成整数——它默认不支持位运算，得显式static_cast - 如果权限集经常增删，建议用脚本生成头文件，而不是人工维护常量顺序
- 不要用
std::pow(2, n)计算掩码——它是浮点运算，不精确且慢
检查权限时最容易忽略的优先级陷阱
& 的优先级低于 != 和 ==，所以 perms & PERM_READ == 0 实际等价于 perms & (PERM_READ == 0)，永远为真（因为 PERM_READ != 0）。
正确写法必须加括号：
if ((perms & PERM_WRITE) != 0) { ... }
// 或更简洁（利用非零即真）
if (perms & PERM_WRITE) { ... }
- 用
!!(perms & flag)强转为 bool 也行，但没必要——C++ 中非零整数在条件中天然为 true - 静态分析工具（如 clang-tidy）能捕获这类错误，建议开启
bugprone-implicit-conversion类规则 - 如果封装成函数（如
has_permission(uint64_t p, uint64_t flag)），内部仍需括号，别依赖调用方加
位运算权限在跨平台序列化时的坑
64位整数本身是标准布局，但直接 memcpy 或写入文件时，字节序（endianness）会影响二进制兼容性。x86_64 是小端，网络协议常用大端。
若需持久化或跨进程传递，要么：
- 统一用网络字节序：存前用
htobe64(perms)，读取后用be64toh(data)（POSIX） - 或改用文本/JSON 表示（如存为十六进制字符串
"0x0000000000000007"），牺牲空间换可读性和跨平台鲁棒性 - 避免直接 reinterpret_cast 到 char 数组再发 UDP 包——不同平台可能对齐要求不同，
uint64_t不保证 1-byte 对齐
真正麻烦的是“权限含义变更”：比如原来第5位是 PERM_EXPORT，后来业务改成 PERM_IMPORT，旧数据就失效了。位掩码本身不带语义版本，靠文档和迁移脚本兜底。
