位运算比算术运算快，因其对应CPU单条指令、通常1个时钟周期完成；而%、/等需多步硬件运算，延迟高。例如奇偶判断用n & 1比n % 2高效，除以2的幂用n >> k替代n / (1
位运算为什么比算术运算快
因为 &、|、^、、<code>>> 这些操作对应 CPU 的单条机器指令，通常 1 个时钟周期就能完成；而 %、/、Math.floor() 等需要多步除法电路或浮点单元参与，延迟高得多。
例如判断奇偶：n % 2 == 0 触发完整除法运算，而 (n & 1) == 0 只需一次按位与 + 一次比较——后者在现代 CPU 上几乎无额外开销。
- 整数除以 2 的幂：用
n >> k替代n / (1 或 <code>n / pow(2, k)，避免除法指令 - 乘以 2 的幂：用
n 替代 <code>n * (1 ，跳过乘法器路径 - 取模 2 的幂（如
n % 8）：等价于n & 7，因 7 是二进制0b111
位掩码如何减少内存和分支开销
用一个 int 的 32 位存 32 个布尔状态，比用 32 个独立 bool 变量省下至少 31 字节（假设 bool 占 1 字节），还避免了数组索引边界检查和指针解引用。
典型例子是权限控制：user_flags & READ_PERMISSION 直接返回非零/零，编译器常将其优化为条件跳转的测试指令（test + jnz），不生成分支预测失败惩罚。
- 设置标志：
flags |= WRITE_PERMISSION - 清除标志：
flags &= ~EXECUTE_PERMISSION - 翻转标志：
flags ^= DEBUG_MODE - 避免 if-else 判断多个开关状态，改用位组合一次查表
位操作在二进制文件解析中的不可替代性
当从 fread() 读出的原始字节流中提取协议字段（比如 TCP 头部的 4 位数据偏移、6 位标志位），必须用位运算做无损切片。文本解析或结构体强制转换会受字节序、对齐、填充影响，而 (buf[12] >> 4) & 0x0F 这类表达式结果确定、可移植、无副作用。
- 左移/右移配合掩码（
& 0xFF）是跨平台提取字节内子字段的唯一可靠方式 - 协议字段常跨越字节边界（如一个 12 位字段横跨
buf[3]和buf[4]），必须靠位拼接：((buf[3] & 0x0F) - 用
fwrite()写入前打包多个小字段到一个整数再写，比逐字段写更少系统调用、更少缓存行失效
容易被忽略的陷阱：符号位与未定义行为
负数右移（>>）在 C/C++ 中行为依赖实现：多数平台做算术右移（补符号位），但标准只规定“实现定义”，移植到某些嵌入式编译器可能出错。Java/JavaScript 强制算术右移，但 JavaScript 的 >>> 是无符号右移——混用会翻车。
- 对有符号整数做位操作前，先转成
unsigned int更安全 1 在 32 位 <code>int上是未定义行为（溢出），应写成1U- 不要对负数用
&提取低位——-1 & 1虽然结果是 1，但逻辑上依赖补码表示，可读性差且易误导 - 位操作优先级低于关系运算符，
a & b == c实际是a & (b == c)，务必加括号：(a & b) == c
实际写高性能底层代码时，最复杂的不是学会怎么用 ^ 或 ，而是清楚哪一步该用位操作、哪一步该交还给编译器自动优化——比如现代编译器能把 <code>n / 8 自动转成 n >> 3，此时硬写位运算反而干扰优化。
