第一次在代码里看到a 2这种写法我足足愣了几秒——这到底是在干嘛把a往左推两格后来搞明白了这玩意儿其实就是把二进制的每一位整体往左挪左边挤出去的直接丢掉右边空出来的位置补 0。听起来特别基础但就是这几个简单的挪位动作撑起了权限管理、像素处理、哈希算法、位图索引这些看起来完全不沾边的领域。这篇主要想聊三件事移位操作在数学上到底等价于什么、不同编程语言对它的定义有哪些让你措手不及的差异、以及真实项目里它到底怎么用才算用对地方。适合刚开始接触位运算的新手也适合想系统补一遍底层基本功的进阶开发者。如果你只想快速记结论可以直接跳到第 5 节看坑位清单。1. 从“乘2和除2”看移位操作的本质1.1 十进制的“补零抹零”与二进制的“挪位”先抛开计算机想想平时写十进制数。12345 这个数尾巴上加个 0 就变成 123450等于原来的 10 倍把最后一位抹掉变成 1234等于原来的十分之一往下取整。为什么因为十进制每一位的位置决定了它的权重往前挪一位就是乘 10往后挪一位就是除 10。二进制同理。1010这个数表示十进制的 10把每一位往左挪一格变成10100就是十进制的 20正好是原来的 2 倍。往右挪一格变成101就是十进制的 5正好是原来的二分之一。所以我们说左移一位等价于乘 2右移一位等价于除 2对正数来说是整除。这个直觉很重要因为硬件里的移位器特别简单一个时钟周期就能完成整个位模式的移动而老 CPU 上的乘法指令可能要吃掉几十个周期。这就是为什么早年的底层优化技巧里到处都是用移位代替乘法的影子。现在的编译器已经足够聪明会帮你自动做这类转换但理解移位本质依然是理解后续一切位运算技巧的地基。1.2 三种移位形态左移、算术右移、逻辑右移很多人只记住了“左移乘二、右移除二”但到了负数、到了无符号数就发现行为对不上原因在于右移其实有两种不同规则。操作常见符号移位规则典型用途左移所有位向左移动右侧补 0左侧溢出丢弃乘 2、组装字段、生成位标志算术右移有符号数所有位向右移动左侧用符号位填充有符号数除以 2、保持负数语义逻辑右移所有位向右移动左侧始终补 0把二进制数据当作无符号串读取左移的行为很统一左右都补 0 就行。关键在于右移如果最高位是符号位直接补 0 会把负数变成正数这完全破坏了“除以 2”的语义所以算术右移会在左侧填充原来的符号位。比如 8 位二进制10000000表示 -128算术右移一位变成11000000也就是 -64仍然保持“越除越小”的方向如果是逻辑右移就变成01000000成了 64语义就崩了。2. Java、C/C、Python 里的移位行为差异2.1 C/C有符号右移是算术移位左移溢出是禁区C/C 的规则比较微妙。对于无符号数一律是逻辑右移高位补 0。对于有符号数标准里写的是“实现定义行为”翻译过来就是交给编译器决定实际几乎所有主流编译器都把有符号做成算术右移。所以你在 x86 上测试负数右移看到的是高位补 1但这不等于你在所有平台上都能拿到同样的结果跨平台编译器换一版就可能出幺蛾子。更危险的是左移。在 C20 之前有符号数左移导致符号位被改变或者发生溢出属于未定义行为。比如1 31这种经典写法在老标准下没人保证它一定算出-2147483648它可能算出任何值也可能把你的程序优化掉。C20 之后标准承认了二进制补码语义有符号左移溢出不再算 UB但历史项目里依然能翻出大量依赖未定义行为的老代码。我的建议很直接有符号左移前先想清楚这个数是不是真有可能越界拿不准就用无符号类型做位运算操作完再转回去。2.2 Java 和 JavaScript掩码取模与无符号右移Java 把位运算定义得很干净所有整数都是有符号的对有符号数做算术右移则完全无视符号位高位补 0。出现的最大价值就是读取那些本质上是“无符号字节”的数据。举个例子你从一个字节流里读到一个0xFF在 Java 里它会被提升成 int 类型的 -1然后你用右移高位扩展出来的全是 1想拿原始字节内容就得跟0xFF做与运算用右移高位直接补 0语义就对了。搞网络协议解析和二进制文件解析的人几乎天天跟这两个运算符打交道。Java 里还有个很容易忽略的细节移位右侧的操作数会被自动取模。int 类型只取低 5 位也就是对 32 取模long 类型只取低 6 位对 64 取模。所以1 33和1 1的结果一模一样。这在多数情况下是贴心设计但调试时确实会有人被它迷惑。JavaScript 更特别。它只有一种数字类型但和会先把操作数转成 32 位有符号整数再移位则转成 32 位无符号整数。因此1 31在 JS 里得到的是负数-2147483648而(1 31) 0才能拿到无符号的2147483648。做位运算前不搞清楚这个转换规则很容易写出看起来对、跑起来全错的代码。2.3 Python 和 Go大整数与严格检查Python 的整数是任意精度的所以1 10000完全合法会生成一个巨大的整数。Python 没有提供因为它的右移在语义上就是算术右移正数补 0负数补 1并且结果是向下取整。-1 1在 Python 里是 -1这个很多人第一次看到都会懵一下。Go 的做法是严格派无符号整数右移做逻辑移位有符号整数右移做算术移位并且移位位数如果超过类型宽度编译器会直接报错运行时动态的移位还有专门的检查不会像 C 那样默默出错也不会像 Java 那样自动取模。这种严格其实省了很多不必要的坑。3. 移位操作在真实项目里的四个高频应用3.1 位标志与权限管理一个 int 搞定一堆开关最经典的应用就是用整数的每一位代表一个开关。Linux 文件权限那套rwxr-xr--的本质就是三组二进制位属主、用户组、其他用户每组三位分别是读、写、执行。读是 4写是 2执行是 1所以rwx加起来是 7r-x是 5r--是 4。一个chmod 754就把一堆权限打包进一个三位数字里这就是位运算在文件系统上的实际落地。在嵌入式开发和游戏开发里这种技巧更常见。你可以定义STATUS_READY 1 0、STATUS_DONE 1 1、STATUS_ERROR 1 2用一个 int 同时追踪多个状态。置位用|判断用清位用 ~。比起写一堆 bool 字段位标志不仅省内存还能一次判断多个条件比如if (state (STATUS_READY | STATUS_DONE))。我维护过的一个状态机模块原来接了八个 bool 变量后来压缩成一个字节不仅结构清爽了连缓存命中率都跟着变好。3.2 图形与像素处理RGB 通道的提取与组装像素颜色在网络和图形领域通常是打包在一个整数里的比如0xFF336699前 8 位是透明度后面红绿蓝各占 8 位。要取出某个通道就需要右移后做掩码unsigned int color 0xFF336699; unsigned char a (color 24) 0xFF; unsigned char r (color 16) 0xFF; unsigned char g (color 8) 0xFF; unsigned char b color 0xFF;反过来组装一个颜色就是把各通道左移到对应位置再拼接unsigned int packed (a 24) | (r 16) | (g 8) | b;这里必须强调只右移不够还要 0xFF。因为右移之后原本高位的位段只是被挪到了低位并没有被自动清掉直接强转成 8 位变量在 C/C 里可能没问题但你要是存进 int 再参与运算高位残留会立刻污染后面的逻辑。每取一个通道就掩一次这是写像素处理的铁律。图像解码、字体渲染、前端 canvas 像素操作底层全在干这种事。3.3 哈希算法与位图索引循环移位和 64 位标记哈希算法里常见一个操作叫循环左移也就是把最左边溢出的位搬到最右边去。写法通常是uint32_t rol(uint32_t x, int n) { return (x n) | (x (32 - n)); }MD5、SHA-1 这类经典哈希算法内部全是这种循环移位加异或的重复组合。理解移位你读那类算法源码时至少不会一头雾水不理解看到一堆和很难不心烦。位索引则是另一个典型场景。假设你要给上亿个 ID 打标记用 bool 数组会吃满内存改用位图就只需八分之一的内存。定位一个 ID 属于哪个 64 位字需要arrIdx id 6因为一个 long 有 64 位除以 64 就是右移 6 位拿到具体 bit 位置用bitIdx id 63因为64 - 1 63。这一步一个取模、一个移位里面的数学关系就是 2 的幂次带来的天然优化。3.4 性能优化能用移位就别用乘除法的边界在哪写底层代码的人经常能听到“用移位代替乘法”的说法。这句话在原理上没错但实际工程里要打个折扣。现代编译器看到x * 2会自动生成左移指令看到x / 2无符号也会自动生成右移指令你手写移位并不会让程序更快反而可能降低可读性。真正值得手写移位的地方是那些语义上就是在操作位模式的场景。比如要求某个数能被 2 的幂整除时用x (n - 1)代替x % n是安全的前提是n必须是 2 的幂。如果n是 6 或 10这个公式就完全不可用。很多人记了个“位运算取模快”就想乱套结果算出一堆错误结果问题不在移位在忘了前置条件。4. 实操演练三个可以直接抄走的小工具4.1 用位移封装颜色通道的解析函数与其背通道布局不如直接封装一组函数把颜色的拆分和组装全部集中到一处。下面这段 Java 代码可以直接抄进图像处理或前端相关的基础库public class ColorUtil { public static int[] split(int argb) { int a (argb 24) 0xFF; int r (argb 16) 0xFF; int g (argb 8) 0xFF; int b argb 0xFF; return new int[] {a, r, g, b}; } public static int pack(int a, int r, int g, int b) { return (a 24) | (r 16) | (g 8) | b; } public static String toHex(int argb) { return String.format(#%02X%02X%02X, (argb 16) 0xFF, (argb 8) 0xFF, argb 0xFF); } }注意pack方法里用的是按位或|而不是加法。两个表达式的二进制结果一样但按位或在语义上更准确地表达了“各通道摆到各自位置”的意图也避免了你担心进位问题的多余思考。我见过有人用加法组装颜色后检查半天找不出一个微妙 bug 的案例其实就是某次该用|的地方写成了通道叠加时进位串到了别的通道。4.2 用逻辑右移读回字节数据处理二进制协议时需要把某个字节当成无符号数据读出来。Java 的 byte 是有符号的直接转 int 会带上符号扩展这就是的用武之地byte[] data {(byte) 0xFF, (byte) 0x80}; int first (data[0] 0xFF); // 255 int second (data[1] 0) 0xFF; // 128等价写法再看一个把 int 转成可视化二进制字符串的小工具顺便练习逻辑右移public static String toBinaryString(int n) { StringBuilder sb new StringBuilder(35); for (int i 31; i 0; i--) { sb.append((n i) 1); if (i % 4 0) { sb.append( ); } } return sb.toString().trim(); }循环里先逻辑右移i位把要判断的那一位挪到最低位再跟 1 做与运算。这个过程看着简单但我最初写的时候顺手用了结果负数打印出来前面全是 1整整排查了十几分钟才发现问题。在打印二进制这种纯位串场景里永远是首选。4.3 用掩码实现环形缓冲区的下标回绕环形缓冲区是嵌入式和高性能网络模块里的老朋友。假设缓冲区容量是 1024也就是 2 的 10 次方下标回绕就可以用掩码而不是取模#define CAP 1024 #define MASK (CAP - 1) int put_index 0; int get_index 0; void put(uint8_t *buf, uint8_t val) { buf[put_index] val; put_index (put_index 1) MASK; } int get(uint8_t *buf) { uint8_t val buf[get_index]; get_index (get_index 1) MASK; return val; }(put_index 1) (CAP - 1)和(put_index 1) % CAP在CAP是 2 的幂时完全等价。为什么能用掩码因为CAP - 1的二进制就是低 10 位全是 1、高位全是 0一个与运算就把超过 1023 的部分全部截断效果自然等同于对 1024 取模。容量选 2 的幂还有个附带好处取模运算在硬件上通常要跑几十个周期而掩码只有一个与指令。虽然现代编译器也可能把常量的 2 次幂取模优化成掩码但写成能让读代码的人一眼看出容量的约束。5. 常见坑位排查位移操作最容易翻车的四个瞬间5.1 负数右移为什么不是整除很多人在正数上验证右移等于整除然后想当然套到负数上。-7 1在 C/C/Java/Python 里都是 -4不是 -3。原因在于算术右移是向下取整而 C 语言整数除法向零取整。如果你要实现向零取整的除法右移后还要根据符号做修正int div2_down_to_zero(int x) { return (x 1) (x 0 (x 1) ? 1 : 0); }这段修正的逻辑是只有负奇数需要加 1因为右移向下取整会比向零取整小 1。很多状态同步和碰撞检测的公式里藏着这种坑表面上是“除 2”实际上是“向下取整”一旦数据出现负奇数结果就偏离预期。5.2 移位位数超过类型的位宽不同类型对超长移位的处理天差地别。C/C 里移位位数大于等于类型宽度是未定义行为编译器想干嘛就干嘛Java 会自动对位数取模1 33等于1 1JavaScript 先转 32 位整数再操作超过 31 位就截断Go 则干脆不让这种代码过编译。所以写底层代码时看到x n里n是个运行时变量一定要先确认它不会越过类型宽度。我见过一个网络协议解析器就是因为没有校验移位位数在特殊报文下跑出了完全不符合预期的解析结果。另外要注意的是循环左移那段代码里的配合关系(x n) | (x (32 - n))当n为 0 时x 32在 C 里是 UB但在常见平台不会崩严谨的实现应该先把n对 32 取模再特判 0 的情况。5.3 判断 2 的幂次一行代码的秘密判断一个正整数是不是 2 的幂有个经典写法int is_power_of_two(int x) { return x 0 (x (x - 1)) 0; }原理很简单2 的幂在二进制里只有一个位是 1。比如 16 是10000减 1 得01111两者的与运算结果是 0而 15 是01111减 1 得01110与运算结果为01110明显不是 0。这个判断只有一次与运算和一次比较比循环数 1 的个数快得多。写内核模块和内存分配器的时候这个惯用法几乎是标配。5.4 从一次性能对比看编译器优化我自己做过一个粗糙的基准测试循环执行一亿次取模运算和掩码运算取模大概是掩码的两倍到三倍耗时。这个数据在不同 CPU 和编译器版本上差异很大但量级关系是稳定的。有意思的是当除数不是 2 的幂时编译器会把取模转换成乘法加移位等一系列指令照样比你手写的直观除法快。所以性能优化的真正结论不是“凡用移位必快”而是“尽量让编译器知道你的数据是 2 的幂”。环形缓冲区容量选 2 的幂、位图数组大小选 2 的幂表面上是内存对齐本质上是在给编译器提供更多优化空间。我在实际开发里养成了一个习惯写移位操作之前先问自己一句“这个数现在到底是有符号还是无符号、我是想保持数值语义还是想操作位串”。这两个问题想清楚了80% 的移位 bug 都能在动手前被消灭掉。还有一个配套小技巧肉眼看不准二进制结果时就立刻打印或写个测试用例把移位前后的二进制串打出来用脚本来验证。位运算这东西信任直觉的同时也要相信可观察的行为毕竟符号扩展、掩码残留这类细节光靠脑子转确实容易翻车。 
长河君 · 2026/10/22 15:55:18 · 阅读 1.2k 位运算探秘：从左移右移的数学本质到权限管理、像素处理实战
第一次在代码里看到a 2这种写法我足足愣了几秒——这到底是在干嘛把a往左推两格后来搞明白了这玩意儿其实就是把二进制的每一位整体往左挪左边挤出去的直接丢掉右边空出来的位置补 0。听起来特别基础但就是这几个简单的挪位动作撑起了权限管理、像素处理、哈希算法、位图索引这些看起来完全不沾边的领域。这篇主要想聊三件事移位操作在数学上到底等价于什么、不同编程语言对它的定义有哪些让你措手不及的差异、以及真实项目里它到底怎么用才算用对地方。适合刚开始接触位运算的新手也适合想系统补一遍底层基本功的进阶开发者。如果你只想快速记结论可以直接跳到第 5 节看坑位清单。1. 从“乘2和除2”看移位操作的本质1.1 十进制的“补零抹零”与二进制的“挪位”先抛开计算机想想平时写十进制数。12345 这个数尾巴上加个 0 就变成 123450等于原来的 10 倍把最后一位抹掉变成 1234等于原来的十分之一往下取整。为什么因为十进制每一位的位置决定了它的权重往前挪一位就是乘 10往后挪一位就是除 10。二进制同理。1010这个数表示十进制的 10把每一位往左挪一格变成10100就是十进制的 20正好是原来的 2 倍。往右挪一格变成101就是十进制的 5正好是原来的二分之一。所以我们说左移一位等价于乘 2右移一位等价于除 2对正数来说是整除。这个直觉很重要因为硬件里的移位器特别简单一个时钟周期就能完成整个位模式的移动而老 CPU 上的乘法指令可能要吃掉几十个周期。这就是为什么早年的底层优化技巧里到处都是用移位代替乘法的影子。现在的编译器已经足够聪明会帮你自动做这类转换但理解移位本质依然是理解后续一切位运算技巧的地基。1.2 三种移位形态左移、算术右移、逻辑右移很多人只记住了“左移乘二、右移除二”但到了负数、到了无符号数就发现行为对不上原因在于右移其实有两种不同规则。操作常见符号移位规则典型用途左移所有位向左移动右侧补 0左侧溢出丢弃乘 2、组装字段、生成位标志算术右移有符号数所有位向右移动左侧用符号位填充有符号数除以 2、保持负数语义逻辑右移所有位向右移动左侧始终补 0把二进制数据当作无符号串读取左移的行为很统一左右都补 0 就行。关键在于右移如果最高位是符号位直接补 0 会把负数变成正数这完全破坏了“除以 2”的语义所以算术右移会在左侧填充原来的符号位。比如 8 位二进制10000000表示 -128算术右移一位变成11000000也就是 -64仍然保持“越除越小”的方向如果是逻辑右移就变成01000000成了 64语义就崩了。2. Java、C/C、Python 里的移位行为差异2.1 C/C有符号右移是算术移位左移溢出是禁区C/C 的规则比较微妙。对于无符号数一律是逻辑右移高位补 0。对于有符号数标准里写的是“实现定义行为”翻译过来就是交给编译器决定实际几乎所有主流编译器都把有符号做成算术右移。所以你在 x86 上测试负数右移看到的是高位补 1但这不等于你在所有平台上都能拿到同样的结果跨平台编译器换一版就可能出幺蛾子。更危险的是左移。在 C20 之前有符号数左移导致符号位被改变或者发生溢出属于未定义行为。比如1 31这种经典写法在老标准下没人保证它一定算出-2147483648它可能算出任何值也可能把你的程序优化掉。C20 之后标准承认了二进制补码语义有符号左移溢出不再算 UB但历史项目里依然能翻出大量依赖未定义行为的老代码。我的建议很直接有符号左移前先想清楚这个数是不是真有可能越界拿不准就用无符号类型做位运算操作完再转回去。2.2 Java 和 JavaScript掩码取模与无符号右移Java 把位运算定义得很干净所有整数都是有符号的对有符号数做算术右移则完全无视符号位高位补 0。出现的最大价值就是读取那些本质上是“无符号字节”的数据。举个例子你从一个字节流里读到一个0xFF在 Java 里它会被提升成 int 类型的 -1然后你用右移高位扩展出来的全是 1想拿原始字节内容就得跟0xFF做与运算用右移高位直接补 0语义就对了。搞网络协议解析和二进制文件解析的人几乎天天跟这两个运算符打交道。Java 里还有个很容易忽略的细节移位右侧的操作数会被自动取模。int 类型只取低 5 位也就是对 32 取模long 类型只取低 6 位对 64 取模。所以1 33和1 1的结果一模一样。这在多数情况下是贴心设计但调试时确实会有人被它迷惑。JavaScript 更特别。它只有一种数字类型但和会先把操作数转成 32 位有符号整数再移位则转成 32 位无符号整数。因此1 31在 JS 里得到的是负数-2147483648而(1 31) 0才能拿到无符号的2147483648。做位运算前不搞清楚这个转换规则很容易写出看起来对、跑起来全错的代码。2.3 Python 和 Go大整数与严格检查Python 的整数是任意精度的所以1 10000完全合法会生成一个巨大的整数。Python 没有提供因为它的右移在语义上就是算术右移正数补 0负数补 1并且结果是向下取整。-1 1在 Python 里是 -1这个很多人第一次看到都会懵一下。Go 的做法是严格派无符号整数右移做逻辑移位有符号整数右移做算术移位并且移位位数如果超过类型宽度编译器会直接报错运行时动态的移位还有专门的检查不会像 C 那样默默出错也不会像 Java 那样自动取模。这种严格其实省了很多不必要的坑。3. 移位操作在真实项目里的四个高频应用3.1 位标志与权限管理一个 int 搞定一堆开关最经典的应用就是用整数的每一位代表一个开关。Linux 文件权限那套rwxr-xr--的本质就是三组二进制位属主、用户组、其他用户每组三位分别是读、写、执行。读是 4写是 2执行是 1所以rwx加起来是 7r-x是 5r--是 4。一个chmod 754就把一堆权限打包进一个三位数字里这就是位运算在文件系统上的实际落地。在嵌入式开发和游戏开发里这种技巧更常见。你可以定义STATUS_READY 1 0、STATUS_DONE 1 1、STATUS_ERROR 1 2用一个 int 同时追踪多个状态。置位用|判断用清位用 ~。比起写一堆 bool 字段位标志不仅省内存还能一次判断多个条件比如if (state (STATUS_READY | STATUS_DONE))。我维护过的一个状态机模块原来接了八个 bool 变量后来压缩成一个字节不仅结构清爽了连缓存命中率都跟着变好。3.2 图形与像素处理RGB 通道的提取与组装像素颜色在网络和图形领域通常是打包在一个整数里的比如0xFF336699前 8 位是透明度后面红绿蓝各占 8 位。要取出某个通道就需要右移后做掩码unsigned int color 0xFF336699; unsigned char a (color 24) 0xFF; unsigned char r (color 16) 0xFF; unsigned char g (color 8) 0xFF; unsigned char b color 0xFF;反过来组装一个颜色就是把各通道左移到对应位置再拼接unsigned int packed (a 24) | (r 16) | (g 8) | b;这里必须强调只右移不够还要 0xFF。因为右移之后原本高位的位段只是被挪到了低位并没有被自动清掉直接强转成 8 位变量在 C/C 里可能没问题但你要是存进 int 再参与运算高位残留会立刻污染后面的逻辑。每取一个通道就掩一次这是写像素处理的铁律。图像解码、字体渲染、前端 canvas 像素操作底层全在干这种事。3.3 哈希算法与位图索引循环移位和 64 位标记哈希算法里常见一个操作叫循环左移也就是把最左边溢出的位搬到最右边去。写法通常是uint32_t rol(uint32_t x, int n) { return (x n) | (x (32 - n)); }MD5、SHA-1 这类经典哈希算法内部全是这种循环移位加异或的重复组合。理解移位你读那类算法源码时至少不会一头雾水不理解看到一堆和很难不心烦。位索引则是另一个典型场景。假设你要给上亿个 ID 打标记用 bool 数组会吃满内存改用位图就只需八分之一的内存。定位一个 ID 属于哪个 64 位字需要arrIdx id 6因为一个 long 有 64 位除以 64 就是右移 6 位拿到具体 bit 位置用bitIdx id 63因为64 - 1 63。这一步一个取模、一个移位里面的数学关系就是 2 的幂次带来的天然优化。3.4 性能优化能用移位就别用乘除法的边界在哪写底层代码的人经常能听到“用移位代替乘法”的说法。这句话在原理上没错但实际工程里要打个折扣。现代编译器看到x * 2会自动生成左移指令看到x / 2无符号也会自动生成右移指令你手写移位并不会让程序更快反而可能降低可读性。真正值得手写移位的地方是那些语义上就是在操作位模式的场景。比如要求某个数能被 2 的幂整除时用x (n - 1)代替x % n是安全的前提是n必须是 2 的幂。如果n是 6 或 10这个公式就完全不可用。很多人记了个“位运算取模快”就想乱套结果算出一堆错误结果问题不在移位在忘了前置条件。4. 实操演练三个可以直接抄走的小工具4.1 用位移封装颜色通道的解析函数与其背通道布局不如直接封装一组函数把颜色的拆分和组装全部集中到一处。下面这段 Java 代码可以直接抄进图像处理或前端相关的基础库public class ColorUtil { public static int[] split(int argb) { int a (argb 24) 0xFF; int r (argb 16) 0xFF; int g (argb 8) 0xFF; int b argb 0xFF; return new int[] {a, r, g, b}; } public static int pack(int a, int r, int g, int b) { return (a 24) | (r 16) | (g 8) | b; } public static String toHex(int argb) { return String.format(#%02X%02X%02X, (argb 16) 0xFF, (argb 8) 0xFF, argb 0xFF); } }注意pack方法里用的是按位或|而不是加法。两个表达式的二进制结果一样但按位或在语义上更准确地表达了“各通道摆到各自位置”的意图也避免了你担心进位问题的多余思考。我见过有人用加法组装颜色后检查半天找不出一个微妙 bug 的案例其实就是某次该用|的地方写成了通道叠加时进位串到了别的通道。4.2 用逻辑右移读回字节数据处理二进制协议时需要把某个字节当成无符号数据读出来。Java 的 byte 是有符号的直接转 int 会带上符号扩展这就是的用武之地byte[] data {(byte) 0xFF, (byte) 0x80}; int first (data[0] 0xFF); // 255 int second (data[1] 0) 0xFF; // 128等价写法再看一个把 int 转成可视化二进制字符串的小工具顺便练习逻辑右移public static String toBinaryString(int n) { StringBuilder sb new StringBuilder(35); for (int i 31; i 0; i--) { sb.append((n i) 1); if (i % 4 0) { sb.append( ); } } return sb.toString().trim(); }循环里先逻辑右移i位把要判断的那一位挪到最低位再跟 1 做与运算。这个过程看着简单但我最初写的时候顺手用了结果负数打印出来前面全是 1整整排查了十几分钟才发现问题。在打印二进制这种纯位串场景里永远是首选。4.3 用掩码实现环形缓冲区的下标回绕环形缓冲区是嵌入式和高性能网络模块里的老朋友。假设缓冲区容量是 1024也就是 2 的 10 次方下标回绕就可以用掩码而不是取模#define CAP 1024 #define MASK (CAP - 1) int put_index 0; int get_index 0; void put(uint8_t *buf, uint8_t val) { buf[put_index] val; put_index (put_index 1) MASK; } int get(uint8_t *buf) { uint8_t val buf[get_index]; get_index (get_index 1) MASK; return val; }(put_index 1) (CAP - 1)和(put_index 1) % CAP在CAP是 2 的幂时完全等价。为什么能用掩码因为CAP - 1的二进制就是低 10 位全是 1、高位全是 0一个与运算就把超过 1023 的部分全部截断效果自然等同于对 1024 取模。容量选 2 的幂还有个附带好处取模运算在硬件上通常要跑几十个周期而掩码只有一个与指令。虽然现代编译器也可能把常量的 2 次幂取模优化成掩码但写成能让读代码的人一眼看出容量的约束。5. 常见坑位排查位移操作最容易翻车的四个瞬间5.1 负数右移为什么不是整除很多人在正数上验证右移等于整除然后想当然套到负数上。-7 1在 C/C/Java/Python 里都是 -4不是 -3。原因在于算术右移是向下取整而 C 语言整数除法向零取整。如果你要实现向零取整的除法右移后还要根据符号做修正int div2_down_to_zero(int x) { return (x 1) (x 0 (x 1) ? 1 : 0); }这段修正的逻辑是只有负奇数需要加 1因为右移向下取整会比向零取整小 1。很多状态同步和碰撞检测的公式里藏着这种坑表面上是“除 2”实际上是“向下取整”一旦数据出现负奇数结果就偏离预期。5.2 移位位数超过类型的位宽不同类型对超长移位的处理天差地别。C/C 里移位位数大于等于类型宽度是未定义行为编译器想干嘛就干嘛Java 会自动对位数取模1 33等于1 1JavaScript 先转 32 位整数再操作超过 31 位就截断Go 则干脆不让这种代码过编译。所以写底层代码时看到x n里n是个运行时变量一定要先确认它不会越过类型宽度。我见过一个网络协议解析器就是因为没有校验移位位数在特殊报文下跑出了完全不符合预期的解析结果。另外要注意的是循环左移那段代码里的配合关系(x n) | (x (32 - n))当n为 0 时x 32在 C 里是 UB但在常见平台不会崩严谨的实现应该先把n对 32 取模再特判 0 的情况。5.3 判断 2 的幂次一行代码的秘密判断一个正整数是不是 2 的幂有个经典写法int is_power_of_two(int x) { return x 0 (x (x - 1)) 0; }原理很简单2 的幂在二进制里只有一个位是 1。比如 16 是10000减 1 得01111两者的与运算结果是 0而 15 是01111减 1 得01110与运算结果为01110明显不是 0。这个判断只有一次与运算和一次比较比循环数 1 的个数快得多。写内核模块和内存分配器的时候这个惯用法几乎是标配。5.4 从一次性能对比看编译器优化我自己做过一个粗糙的基准测试循环执行一亿次取模运算和掩码运算取模大概是掩码的两倍到三倍耗时。这个数据在不同 CPU 和编译器版本上差异很大但量级关系是稳定的。有意思的是当除数不是 2 的幂时编译器会把取模转换成乘法加移位等一系列指令照样比你手写的直观除法快。所以性能优化的真正结论不是“凡用移位必快”而是“尽量让编译器知道你的数据是 2 的幂”。环形缓冲区容量选 2 的幂、位图数组大小选 2 的幂表面上是内存对齐本质上是在给编译器提供更多优化空间。我在实际开发里养成了一个习惯写移位操作之前先问自己一句“这个数现在到底是有符号还是无符号、我是想保持数值语义还是想操作位串”。这两个问题想清楚了80% 的移位 bug 都能在动手前被消灭掉。还有一个配套小技巧肉眼看不准二进制结果时就立刻打印或写个测试用例把移位前后的二进制串打出来用脚本来验证。位运算这东西信任直觉的同时也要相信可观察的行为毕竟符号扩展、掩码残留这类细节光靠脑子转确实容易翻车。