位运算符是编译器直译为单条CPU指令的底层操作，无函数调用开销且不受隐式类型提升干扰，但要求操作数类型明确、对齐、无符号。
位运算符在 C++ 里不是“炫技工具”，而是内存/硬件交互的刚需
直接说结论：C++ 的 &、|、^、~、、<code>>> 是编译器直译成单条 CPU 指令的底层操作，没有函数调用开销，也不受类型提升隐式转换干扰——但前提是操作数类型明确、对齐、无符号。
常见错误现象：int a = -1; cout > 1); 输出 -1（算术右移），而你本意可能是逻辑右移；又或者 1 在 32 位 int 上触发未定义行为（UB）。
- 永远优先用
uint8_t、uint32_t等固定宽度整型做位操作，避免平台依赖 - 右移有符号数时，编译器按符号位填充，想逻辑右移就先转
unsigned再移 和 <code>>>的右操作数必须小于左操作数位宽，否则行为未定义（比如uint8_t x; x 是 UB）
用位掩码（bitmask）代替布尔数组或枚举开关最省空间
场景很典型：驱动寄存器配置、协议字段打包、状态机标志位。一个 uint32_t 能存 32 个开关，比 std::vector<bool></bool> 或 32 个 bool 成员变量更紧凑、更易原子读写。
关键不是“怎么写掩码”，而是“怎么维护可读性”。别手写 0x00000004，用命名常量 + 左移构造：
立即学习“C++免费学习笔记（深入）”；
constexpr uint32_t FLAG_READY = 1U << 0; constexpr uint32_t FLAG_ERROR = 1U << 1; constexpr uint32_t FLAG_ACTIVE = 1U << 2;
常见错误现象：忘记加 U 后缀导致 1 被当 <code>int 计算溢出；或用 == 判断掩码是否置位（应为 &）。
- 判断某位是否为 1：用
flags & FLAG_READY，非零即真，别写(flags & FLAG_READY) == FLAG_READY - 置位：用
flags |= FLAG_ERROR，不是flags = flags | FLAG_ERROR（虽等价但不惯用） - 清位：用
flags &= ~FLAG_ACTIVE，注意~作用于无符号数才安全
异或 ^ 不只是加密玩具，它是无临时变量交换和奇偶校验的物理基础
硬件层面，a ^ b ^ b == a 是门电路级恒等式，所以它被用于 ECC 内存、RAID 5 校验、寄存器原地交换——这些都不是“算法题技巧”，而是真实系统设计选择。
示例：寄存器级交换两个 GPIO 引脚状态，不能用中间变量（寄存器资源紧张）：
volatile uint32_t* reg = ...; *reg ^= (1U << pin_a) ^ (1U << pin_b); // 原子翻转两引脚
容易踩的坑：a ^= b; b ^= a; a ^= b; 看似无临时变量，但如果 a 和 b 指向同一地址（比如 swap(&x, &x)），结果是 0 —— 因为 a 和 b 变成同一块内存，第一次 ^= 就清零了。
- 异或校验只检单比特错，不防双比特错，别在高可靠性场景单独依赖它
- 用
^实现开关逻辑（比如 LED 翻转）时，确保操作是原子的，否则中断可能打断中间态 - 别用
^替代!=判断两个整数是否相等——语义不清，且对浮点数完全失效
移位替代乘除要小心符号、溢出和编译器优化反直觉行为
写 x 代替 <code>x * 8 看似高效，但现代编译器（GCC/Clang -O2）基本都会自动优化，手动替换反而降低可读性；真正需要手动移位的，是涉及硬件时序、DMA 对齐、或必须控制指令序列的场合。
性能影响其实次要，兼容性风险更实际：ARM Cortex-M 默认开启未对齐访问陷阱，*(uint32_t*)(buf + 1) 会硬 fault，但用移位拼字节就绕过对齐检查：
uint32_t val = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
常见错误现象：用 int 移位后参与有符号计算，导致高位符号扩展污染结果；或假设 sizeof(int) == 4，在 64 位平台出错。
- 移位前务必 cast 到足够宽的无符号类型，如
(uint32_t)byte - 左移后若要赋给
int，确认值不超INT_MAX，否则有符号溢出是未定义行为 - 编译器对
const表达式移位会常量折叠，但对运行时变量移位不一定生成最优指令，别盲目迷信
位运算的复杂点不在语法，而在它把“数据”和“布局”绑死——改一个 bit 可能跨字节、越 cache line、触犯内存屏障。写的时候得心里有内存映射图，而不是只盯着表达式算得对不对。
