& 是按位与，&& 是逻辑与，混用会导致掩码判断失效；如 if (flags && enable_log) 错误地变成逻辑判断而非位检测，正确应为 if (flags & enable_log)。
为什么 & 和 && 混用会悄悄改掉变量值？
因为 & 是按位与，&& 是逻辑与，编译器不会报错但行为完全不同。比如 if (x & 0x01) 检查最低位是否为 1，而 if (x && 0x01) 只判断 x 是否非零——后者根本没做位操作。
- 常见错误：把掩码判断写成
if (flags && ENABLE_LOG)，本意是检查某标志位，结果变成逻辑真值判断 - 真实场景：状态寄存器读取、协议字段解析、权限掩码校验（如
ACCESS_READ | ACCESS_WRITE） - 注意
int和unsigned int对右移>>的处理差异：有符号数右移可能补符号位，导致高位意外置 1
std::bitset 和原生整数位运算怎么选？
不追求极致性能时，std::bitset 更安全；要嵌入硬件寄存器或对齐特定字节布局时，必须用原生整数 + 位运算。
-
std::bitset自动管理边界，支持.test()、.set()、.flip()，但无法直接映射到内存地址 - 原生整数（如
uint32_t）可配合volatile用于寄存器操作，例如*(volatile uint32_t*)0x40020000 |= (1U - 性能影响：现代编译器对简单位运算优化极好，
std::bitset在栈上构造几乎无开销，但频繁调用.to_ulong()可能触发隐式转换成本
左移 超出位宽会怎样？
行为未定义（UB），不是截断，也不是模运算。GCC/Clang 可能静默丢弃高位，但启用 -fsanitize=undefined 时会崩溃。
- 典型现象：在 32 位系统上写
1 ，结果可能是 0 或 1，取决于编译器和优化级别 - 安全写法：先检查位移量，如
if (shift (1) - 注意：C++20 引入了
std::rotl/std::rotr，需要循环移位时优先用它们，而非手动拼接|
用位域（bit-field）结构体时哪些坑不能踩？
位域的内存布局、对齐、符号扩展全由编译器决定，跨平台代码里基本等于自找麻烦。
立即学习“C++免费学习笔记（深入）”；
- 常见错误：定义
struct { int flag : 1; };后假设sizeof是 1——实际可能是 4 或更多，且flag可能被解释为有符号数 - 替代方案：用普通整型成员 + 掩码访问，比如
uint8_t flags;配合flags & (1U - 唯一勉强可用的场景：仅限单编译器、固定 ABI 的嵌入式驱动中，且必须加
static_assert校验布局
事情说清了就结束。位运算本身不难，难的是它藏在底层细节里，一不留神就让调试时间翻倍。
