设第n位用flags |= (1u
用 & | ^ ~ 和移位操作直接读写标志位
C++里没“位变量”，但可以用整型（uint8_t、uint32_t等）当位容器，靠位运算原子地操作单个 bit。关键不是“能不能”，而是“怎么写才不掉坑”。
常见错误是手写 if (flags & 0x04) 却忘了括号优先级，或者用 = 而非 |= 覆盖其他位。
- 设第
n位（从 0 开始）：用flags |= (1U —— <code>1U防止左移溢出符号位 - 清第
n位：用flags &= ~(1U —— <code>~必须包在括号里，否则只取反1U - 读第
n位：用(flags & (1U —— 别直接当 bool 用，<code>0x02和0x04都是非零，但值不同 - 翻转第
n位：用flags ^= (1U
为什么推荐用 std::bitset 而不是裸位运算？
裸位运算快，但易错；std::bitset 封装安全，编译期确定大小，且多数实现会内联为同样高效的指令。它不是“性能妥协”，而是把重复逻辑交给标准库验证。
典型误用：有人为“省一个字节”坚持手写位操作，结果改需求加第 9 个标志时，硬编码的 uint8_t 溢出，又不敢换类型怕影响 ABI。
立即学习“C++免费学习笔记（深入）”；
-
std::bitset flags;支持flags.set(3)、flags.test(7)、flags.reset(1)，语义清晰 - 底层仍用整数存储，
flags.to_ulong()可随时导出原始值，和旧协议/寄存器交互无压力 - 不支持运行时大小，所以别用
std::bitset<n></n>去接用户输入的n—— 编译不过
用 enum class + 位掩码定义标志时，必须显式指定底层类型
默认 enum class 底层类型未指定，编译器可能选 int，导致 static_cast<int>(FlagA) | static_cast<int>(FlagB)</int></int> 在 16 位平台意外截断。
更隐蔽的问题是：不同枚举项若没用 1U 显式赋值，可能生成非 2 的幂的值（比如自增），那就根本不是“标志位”了。
- 正确写法：
enum class Flags : uint32_t { Read = 1U - 别写
Read = 1, Write = 2, Execute = 4—— 看似一样，但失去可读性和扩展性（比如想跳过第 3 位） - 组合多个标志必须用
|，不能用+—— 后者在某些优化级别下可能不被识别为位操作，影响常量折叠
内存对齐与原子性：单字节标志位不一定线程安全
哪怕只操作一个 uint8_t 的某一位，flags |= (1U 也不是原子的：CPU 通常按字（word）读-改-写，多核下可能丢失其他位的并发修改。
这不是“理论风险”。嵌入式里外设寄存器状态位、服务端连接状态标记，都栽在这儿。
- 需要原子操作，就用
std::atomic<uint8_t></uint8_t>，再配合.fetch_or(1U 等成员函数 - 别依赖
volatile—— 它只禁用优化，不提供原子性或内存序保证 - 如果标志位属于某个大结构体，注意编译器可能因对齐插入填充字节，
sizeof不等于各字段和；用[[no_unique_address]]或#pragma pack要格外小心
最麻烦的其实是调试：位操作没有符号名，core dump 里看到 0x1a 得手动拆成二进制再查文档。所以哪怕项目再小，也值得花两分钟写个 constexpr 辅助函数来打印当前哪些位被置起。
