std::bitset支持&、|、^、~、&=、|=、^=，但不支持直接移位操作；移位需显式指定宽度，否则行为未定义。
std::bitset 支持哪些位运算符
std::bitset 原生支持 &（与）、|（或）、^（异或）、~（非）、&=、|=、^=，但不支持 / >>（移位）直接作用于 bitset 对象本身——这些移位操作返回的是新 bitset，且需显式指定宽度，否则行为未定义。
常见错误是误以为 b 会就地左移并补 0，实际它确实能编译，但语义上等价于 b = b ，且若移出范围（如 bitset 左移 3 位），高位直接丢弃，低位补 0，不会报错也不会截断警告。
-
bitset a = 0b1010'0000; auto b = a >> 3;→ 得到0b0000'0101 bitset c = a → 得到0b0000'0000（全移出）- 移位后长度不变，超出位宽的部分永远被静默丢弃
用 operator[] 设置单个标志位是否线程安全
operator[] 返回的是 std::bitset::reference，一个代理类，其赋值操作（如 b[3] = true）本质是原子的位写入——但仅限于单个 bit；它不保证对整个 bitset 的读-改-写操作原子，也不提供内存序控制。
这意味着：在多线程中，如果你只做 flags[i] = true 或 flags[j] = false，且各线程操作的下标互不重叠，那没问题；但若两个线程同时执行 flags[5] = true 和 flags[5] = false，结果取决于最后执行者，无数据竞争但行为不确定；更危险的是混合使用 set() 和 operator[]，因为 set() 内部可能涉及整字写入，和 operator[] 的位级写入可能产生撕裂（tearing）。
立即学习“C++免费学习笔记（深入）”；
- 避免跨线程共享同一
std::bitset并并发修改任意位 - 如需线程安全标志集合，优先用
std::atomic+ 手动位操作，或封装带锁的 bitset 类 -
test()、any()、none()是只读，可安全并发调用
bitset 和 uintN_t 做标志位哪个更快
绝大多数场景下，uint32_t 或 uint64_t 的位操作比 std::bitset 更快——因为前者直接映射到 CPU 指令（如 and、or、bt），而 std::bitset 在某些实现中会引入额外函数调用开销（尤其 debug 模式下检查边界），且编译器对原生整型的优化更激进。
但 std::bitset 的优势不在速度，而在类型安全与表达力：b.set(7) 比 flags |= (1U 更易读；b.count() 比手写 popcount 更可靠；b.to_ulong() 自动处理越界转换异常。
- 性能敏感循环内（如网络包解析、图形掩码计算），优先用
uint64_t+ 位操作宏 - 配置项、状态机标志、API 参数等需要清晰语义的地方，用
bitset提升可维护性 -
bitset到bitset通常被优化为单个机器字，但bitset就必然涉及多字操作，性能下降明显
如何把 std::bitset 转成可移植的整数或字符串
std::bitset 提供 to_ulong() 和 to_ullong()，但它们在 bitset 值超出目标整型范围时抛 std::overflow_error，不是隐式截断。例如 bitset.to_ulong() 必炸，哪怕你只关心低 32 位。
想安全取底 n 位整数值，得手动掩码：(b.to_ullong() & ((1ULL ；想转二进制字符串，b.to_string() 最直接，但它从高位开始（MSB-first），即 bitset("1010") 的 to_string() 是 "1010"，而非按内存布局反转。
- 不要依赖
to_ulong()处理任意大小 bitset，先用b.size() 检查 - 序列化到文件或网络时，建议用
b.to_string()或逐字节提取b.to_bytes()（C++23 新增） -
to_string()返回std::string，每个字符是'0'或'1'，不可直接 reinterpret_cast 为整数
实际项目里，最常被忽略的是 bitset 移位的静默截断行为和跨线程修改时的非原子性组合风险——这两点往往在压力测试或特定硬件上才暴露，调试成本远高于初期加一行注释或换种实现。
