用 std::uint32_t 存权限比 std::vector<bool> 快且省内存，因其将权限映射为二进制位，32个权限仅需一个 uint32_t；超64时应分组而非硬用 bitset，权限常量须用 1U。
用 std::uint32_t 存权限比用 std::vector<bool> 快且省内存
位运算权限系统本质是把每个权限映射成一个二进制位，比如“读=第0位”“写=第1位”“删=第2位”，这样 32 个权限只要一个 std::uint32_t 就能装下。而用 std::vector<bool> 或 std::set<int> 不仅内存占用翻几倍，每次判断还得遍历或哈希查找。
实操建议：
- 固定权限总数 ≤ 64 时，优先选
std::uint64_t；超过就分组（如按模块拆成多个字段），别硬上std::bitset—— 它不支持原子操作，多线程下容易出问题 - 权限常量必须用 1U 0x10 这类魔法数，否则移位错一位就全乱
- 别用
enum class直接当位掩码——它默认是int，隐式转换可能触发编译器警告，显式转成std::uint32_t更稳
operator& 和 operator|= 是权限判断与赋权的核心操作
判断用户是否有“读+写”权限，不是 if (perm == READ | WRITE)，而是 if ((perm & (READ | WRITE)) == (READ | WRITE))；赋权也不是 perm = READ | WRITE，而是 perm |= READ | WRITE。前者是“是否完全匹配”，后者才是“是否包含全部要求权限”。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 用
==判断权限存在 → 实际只匹配了权限集合的精确值，漏掉用户还拥有其他权限的情况 - 用
=赋权 → 清空原有权限，变成“覆盖”而非“追加” - 没加括号，比如
perm & READ | WRITE→ 位与优先级高于位或，等价于(perm & READ) | WRITE，逻辑彻底跑偏
位域（:N）不适合做权限存储，只适合解析协议字段
有人想用 struct { uint32_t read : 1, write : 1, exec : 1; }; 管理权限，这在绝大多数场景下是陷阱。C++ 标准不保证位域的内存布局跨平台一致，调试器也常显示不准，更别说原子性——两个线程同时改不同位域，仍可能因写入同一机器字导致数据竞争。
正确做法：
- 权限存储统一用整型变量（
std::uint32_t等），所有增删查都走位运算函数封装 - 位域只用于已知固定格式的二进制协议解析（比如解析 TCP 头里的 ACK flag），且必须配合
#pragma pack(1)和静态断言校验大小 - 如果真要封装操作，写个轻量 wrapper 类，重载
has()、enable()、disable()，内部还是用整型+位运算
多线程下权限变更必须用 std::atomic<uint32_t>
权限变量被多个线程读写时，普通 uint32_t 的 |= 不是原子操作：读-改-写三步中间可能被中断，导致某次赋权丢失。直接上 std::mutex 又太重，尤其高并发鉴权场景会成瓶颈。
实操要点：
- 声明为
std::atomic<std::uint32_t> permissions{0};，读用.load()，赋权用.fetch_or(mask)，清权用.fetch_and(~mask) - 避免用
.store()直接写入新值——它会覆盖其他线程刚设的权限 - 注意
fetch_or返回的是旧值，如需判断“本次是否首次开启某权限”，得自己比对
