1. 为什么每个写代码的人都该把二进制当母语干了这么多年开发我越来越觉得二进制这东西就像空气——平时感觉不到它的存在可一旦出问题十有八九是它在背后捣鬼。你可能写过无数行代码用过各种高级语言但真正让你在排查线上事故时心里有底的往往是对二进制层面的理解深度。举个最常见的场景某天接口返回的数据莫名其妙多了个负号或者两个看起来相等的浮点数比较结果却是false再或者一个位运算把整个权限系统搞崩了——这些问题的根子基本都能追溯到二进制这个地基上。二进制基础知识听起来像是大学课本第一章的内容但它实际覆盖的范围远比大多数人想象的要广。从最底层的位与字节、原码反码补码的转换逻辑到整数的溢出行为、浮点数的精度陷阱再到位运算在权限控制、状态压缩、哈希计算中的实战应用这一整套东西构成了程序员理解计算机行为方式的底层框架。你可以不手写汇编但你得知道为什么0.1 0.2 ! 0.3你可以天天用框架但你得明白为什么一个int在某些场景下会突然变成负数。这篇内容适合谁看我的判断是三类人最需要第一类是刚入行不久、对计算机底层还停留在“知道有这回事”阶段的开发者补齐这块知识能让你后面学什么都快半拍第二类是工作几年但一直做上层业务、遇到底层问题就发怵的工程师把二进制捡起来能显著提升你排查疑难杂症的底气第三类是对性能敏感、想做优化但不知道从哪下手的同学位运算和二进制思维往往是性价比最高的优化切入点。下面我按自己带人、踩坑、复盘的经验把二进制这块从思路到实操完整拆一遍。2. 整体认知框架与学习路径拆解2.1 二进制到底在解决什么问题很多人学二进制的方式是背转换规则除2取余、乘2取整背完就完事了。这种方式的问题在于你记住的是操作步骤而不是它存在的理由。二进制在计算机里承担的核心角色其实就一个用两种稳定状态来表达一切信息。电路的通和断、电平的高和低、磁介质的两个方向这些物理现象天然只有两个稳定态所以用0和1来映射是最省事、最不容易出错的选择。理解了这个前提后面所有的设计就都顺了。为什么整数要用补码表示因为用补码可以把减法统一成加法硬件上只需要一套加法电路就能同时处理加减法省掉了专门的减法器。为什么浮点数会有精度问题因为二进制小数只能精确表示分母是2的幂的分数0.1在二进制里是无限循环小数存进有限位数的容器里必然被截断。这些“为什么”才是二进制知识的骨架转换规则只是皮肉。我在带新人的时候有个习惯不让他们先背转换方法而是先问一个问题——如果让你用只有两个刻度的尺子去量所有长度你会怎么设计这个问题能逼着人去想“表示范围”和“精度”的权衡而这恰恰是二进制所有设计的核心矛盾。想通了这个后面学原码反码补码、学浮点数的IEEE 754标准就都是在看别人怎么解这道题。2.2 学习路径的优先级排序二进制相关知识面很宽但不同内容的实战价值差别巨大。我按自己的经验给一个优先级排序你可以对照着查漏补缺。优先级知识模块实战出场频率建议投入P0补码与整数溢出极高几乎每周都会遇到相关bug必须吃透P0位运算的语义与常见套路极高权限、状态、优化都靠它必须吃透P1进制转换二/八/十/十六高调试和读配置时常用熟练即可P1浮点数精度与表示高涉及金额、科学计算必踩理解原理P2字节序大小端中跨平台通信和文件解析时遇到知道怎么排查P2位图与状态压缩中大数据量和性能优化场景掌握思路这个排序的逻辑很简单出场频率决定投入产出比。补码和位运算几乎贯穿所有代码浮点数精度问题在业务系统里迟早要撞上而字节序这类问题虽然不常遇到但一旦遇到就是硬骨头至少得知道排查方向。至于更深的内容比如位域、SIMD相关的二进制操作等前面这些吃透了再往上走不迟。2.3 一个容易被忽略的认知二进制思维比二进制知识更重要我见过不少人对补码转换倒背如流但写代码时依然会写出if (a - b 0)这种在溢出场景下会翻车的判断。问题不在于知识不够而在于没有形成二进制思维——也就是在写每一行涉及数值和位的代码时脑子里能自动浮现出它在内存里的样子。举个我自己的例子。早年做权限系统一开始用数据库存角色和权限的关联表查询时要join好几张表。后来改成用一个整数的不同二进制位表示不同权限判断权限就是一次按位与操作性能提升非常明显。这个改造的技术门槛其实很低难的是当时能不能想到“一个整数的32个位就是32个开关”这个视角。二进制思维的本质就是把“数值”和“位的集合”这两种视角自由切换的能力。培养这种思维没有捷径但有方法每次遇到数值相关的bug强迫自己把相关变量在内存里的二进制形式画出来。画上十几次你就会发现很多看似诡异的现象其实一目了然。下面几个章节我会结合具体场景把这种“画出来看”的方法贯穿进去。3. 核心概念深挖与关键细节解析3.1 补码为什么负数在计算机里长那样补码是二进制知识里最容易被教歪的部分。很多教材上来就是“取反加一”但不说为什么。我用一个生活化的类比来解释假设你有一个只能显示两位数的里程表从00到99转一圈回到00。现在你想表示“倒退1公里”怎么表示答案是99因为从99再往前拨一格就回到00效果和倒退1公里完全一样。补码就是这个思路——用“往前转一大圈”来表示“往后退一小步”。具体到8位整数范围是0到255。要表示-1就用255二进制11111111因为255加1会溢出回到0效果等同于-1加1等于0。所以负数的补码本质上就是“模2的n次方下的补数”。理解了这一点取反加一这个操作就有了来由对一个数取反相当于用全1去减它再加1正好凑成模运算下的补数。这个原理直接决定了一个实战中极其常见的坑整数溢出。8位有符号整数的范围是-128到127当你算127加1时二进制是01111111加00000001等于10000000按补码解读就是-128。这不是bug是设计使然。我在实际项目里遇到过最典型的一次某统计模块用int累加一个理论上不会超过21亿的计数结果某天数据量暴涨直接溢出成负数下游报表全乱。后来改成long并加了溢出检测才稳住。注意判断两个数相加是否溢出不要用结果去反推而要用符号位的变化来判断。同号相加结果变号就是溢出。这个判断方式在任何位宽下都成立。3.2 位运算的语义地图六个运算符各自的脾气位运算一共六个与、或、异或、取反、左移、右移。单看定义谁都会但真正用好需要知道每个运算符在实战中的“性格”。按位与的性格是“筛子”常用来做掩码提取和清零。比如从一个整数里取低8位就是x 0xFF。按位或|的性格是“开关合上”常用来置位。按位异或^的性格最特别它是“相同为0不同为1”所以有两个妙用一是翻转指定位二是利用a ^ a 0和a ^ 0 a来做“找出唯一出现一次的数”这类问题。取反~在实战中单独用得少更多是配合掩码使用。左移和右移需要特别注意有符号和无符号的区别。左移x n等价于乘以2的n次方但要注意高位溢出。右移则分算术右移和逻辑右移有符号数右移时高位补符号位算术右移无符号数右移时高位补0逻辑右移。这个区别在跨语言时尤其容易翻车比如Java的是算术右移是逻辑右移而Python的右移行为又和它们不同。运算符常见用途典型陷阱掩码提取、判断奇偶、清零掩码写错位导致误判|置位、合并标志与加法混用导致重复置位出错^翻转位、找唯一数、简单加密对自身异或清零的语义被误用~配合掩码构造有符号数取反后符号位变化快速乘2的幂溢出、负数左移的行为差异快速除2的幂有符号右移的舍入方向关于右移的舍入方向有个细节值得单独说算术右移对负数是向下取整比如-3右移1位是-2而不是-1。如果你用右移来实现“除以2”在负数场景下结果会和除法不一致。这个坑我在做分页计算时踩过页码为负的边界情况直接算出了错误的偏移量。3.3 浮点数精度问题不是bug是特性浮点数的二进制表示遵循IEEE 754标准核心思路是把一个数拆成符号位、指数位和尾数位三部分类似科学计数法。单精度float是1位符号、8位指数、23位尾数双精度double是1位符号、11位指数、52位尾数。尾数位决定了精度指数位决定了范围。精度问题的根源在于二进制只能精确表示形如“分母是2的幂”的分数。0.5、0.25、0.125这些都没问题但0.1在二进制里是无限循环小数存进23位或52位的尾数里必然被截断截断就产生误差。所以0.1 0.2在浮点数世界里不等于0.3而是等于0.30000000000000004。这不是哪个语言的问题是所有遵循IEEE 754的平台共同的行为。实战中处理金额时我的建议是坚决不用浮点数改用整数以最小货币单位存储比如以分为单位存金额或者用定点数、高精度库。如果非要用浮点数比较永远不要用而是判断两者差值是否小于一个足够小的阈值。这个阈值怎么选一般取业务精度要求的一半比如要求精确到小数点后两位阈值取0.005左右。提示浮点数的特殊值也值得记一下。NaN和任何数比较包括自己都返回false正无穷和负无穷有明确的运算规则。调试时看到NaN第一反应应该是去找0除以0或者无穷减无穷这类操作。3.4 字节序数据在内存里的排列方向字节序讲的是多字节数据在内存中的存放顺序。大端序是高字节存在低地址小端序是低字节存在低地址。比如整数0x12345678大端序在内存里是12 34 56 78小端序是78 56 34 12。x86架构是小端序网络传输协议通常规定用大端序所以做网络编程时经常需要做字节序转换。这个问题在日常业务开发里很少遇到但一旦涉及跨平台文件解析、网络协议实现、或者和硬件设备通信就是绕不过去的坎。我排查过一次数据解析错误现象是读出来的数值总是莫名其妙地大了很多倍最后发现是对方设备发的是大端序我方按小端序解析了。排查方法很简单把收到的原始字节按十六进制打印出来对照协议文档一看便知。判断本机字节序有个经典的小技巧定义一个16位整数1然后把它按字节读取如果第一个字节是1就是小端序是0就是大端序。这个技巧的原理就是利用了1在两种字节序下低字节位置的不同。4. 实操过程与核心环节落地4.1 手把手做一次进制转换的完整推演进制转换是二进制的基本功但我要讲的不是背规则而是建立“位权”的直觉。以十进制转二进制为例除2取余法的每一步其实都在回答一个问题这个数里包含多少个2的幂。比如把156转成二进制过程如下156除以2得78余0这个0就是最低位因为156是偶数不含2的0次方。78除以2得39余0第二位也是0。39除以2得19余1第三位是1。继续下去得到10011100。验证一下128加16加8加4等于156对应位正好是第7、4、3、2位为1其余为0完全吻合。反过来二进制转十进制就是把每个为1的位对应的2的幂加起来。这里有个提速技巧记住2的0到10次方的值1、2、4、8、16、32、64、128、256、512、1024大部分日常场景够用了。十六进制和二进制之间的转换更简单因为一位十六进制正好对应四位二进制直接分组替换即可这也是为什么调试时大家都爱看十六进制——它和二进制之间的转换不需要计算。4.2 用位运算实现一个权限系统这是位运算最经典的实战场景我把完整思路和代码走一遍。假设一个系统有读、写、删、管四个权限用整数的四个位表示READ 1 0 # 0001 WRITE 1 1 # 0010 DELETE 1 2 # 0100 ADMIN 1 3 # 1000 def grant(user_perm, perm): return user_perm | perm def revoke(user_perm, perm): return user_perm ~perm def check(user_perm, perm): return (user_perm perm) perm这段代码的关键在于三个操作的语义授权是“或”因为要把对应位合上回收是“与上取反”因为要把对应位清零而保留其他位检查是“与之后等于目标”因为要确认目标位全部为1。注意检查时不能写成user_perm perm直接判断真值因为如果perm包含多个位只要有一个位匹配结果就非零会误判。这个细节我在code review里见过不止一次。这个方案的优势不只是省存储更重要的是判断效率——一次位运算就能完成权限校验不需要查表或join。扩展到32位就是32种权限扩展到64位就是64种对于绝大多数系统绰绰有余。如果权限种类超过位宽再考虑分组或者换方案。4.3 整数溢出的检测与防御实操整数溢出的防御要分场景。对于业务代码最稳妥的做法是选用足够宽的整数类型并在关键计算处加检测。以32位有符号整数加法为例检测逻辑如下INT_MAX 2**31 - 1 INT_MIN -2**31 def safe_add(a, b): result a b if a 0 and b 0 and result 0: raise OverflowError(positive overflow) if a 0 and b 0 and result 0: raise OverflowError(negative overflow) return result检测的原理就是前面说的符号位变化两个正数相加结果变负或者两个负数相加结果变非负都是溢出。乘法的检测更复杂一些可以用除法反推或者用更大位宽的类型先算再判断是否超出范围。对于性能敏感的底层代码检测本身的开销可能不可接受这时候的策略是“设计上避免溢出”——比如限制输入范围、用无符号数做计数、或者用饱和运算代替回绕。选择哪种策略取决于业务对正确性和性能的权衡没有一刀切的答案。4.4 浮点数比较的正确姿势浮点数比较的实操要点我整理成一个对照表覆盖常见场景场景错误做法正确做法判断相等a babs(a - b) epsilon判断大于a ba b epsilon金额计算用float/double用整数分或高精度库累加求和直接循环累加用Kahan求和或排序后累加判断是否为0a 0abs(a) epsilonepsilon的选取要结合业务精度。有个经验法则如果数据量级在1左右epsilon取1e-9比较合适如果量级到1e6epsilon要相应放大到1e-3左右因为浮点数的绝对精度随量级增大而降低。这个规律来自浮点数的表示方式——尾数位数固定指数越大能表示的相邻两个数之间的间隔就越大。5. 常见问题排查与避坑经验实录5.1 那些年我踩过的二进制坑第一个坑是位运算的优先级。在C系语言里位运算的优先级低于比较运算所以x 1 0会被解析成x (1 0)结果永远是0。正确写法是(x 1) 0。这个坑的隐蔽性在于代码能编译能运行只是逻辑全错。我现在的习惯是位运算一律加括号不给优先级任何犯错的机会。第二个坑是有符号数的右移。前面提过算术右移对负数是向下取整我在做哈希分桶时用hash n来算桶索引结果负数哈希值算出来的桶索引偏了一位导致部分数据永远落不到正确的桶里。修复方法是对哈希值先取绝对值或者转成无符号再移位。第三个坑是十六进制字面量的符号问题。在某些语言里0xFFFFFFFF被当作有符号的-1而不是无符号的4294967295做比较时会出意外。处理方法是显式声明无符号类型或者用语言提供的无符号字面量语法。5.2 排查二进制相关问题的通用套路遇到疑似二进制层面的问题我有一套固定的排查流程按顺序走基本能定位先把相关数值按二进制或十六进制打印出来肉眼观察位的模式。很多问题在这一步就暴露了比如本该是正数的值最高位是1。确认数据类型的位宽和符号性。是8位还是32位有符号还是无符号这决定了同样的位模式会被解读成什么值。检查所有位运算的括号和优先级确认运算顺序符合预期。如果是跨系统问题检查字节序是否一致。如果是浮点数问题检查是否有精度损失或者特殊值参与运算。这套流程的价值在于把“猜”变成“看”。二进制问题的特点是现象诡异但原因明确只要能看到位的真实状态答案往往就在眼前。5.3 常见问题速查表现象可能原因排查方向正数突然变负数整数溢出或符号位误读检查位宽和运算结果最高位两个相等的浮点数比较为false浮点精度误差改用阈值比较权限判断总是通过检查逻辑写成了非零判断改为与掩码后等于掩码数据解析数值偏大很多倍字节序不一致打印原始字节对照协议位运算结果完全不符预期运算符优先级问题给所有位运算加括号移位结果和除法不一致负数算术右移的舍入方向确认是否需要逻辑右移5.4 几条压箱底的经验第一条调试二进制问题时善用计算器的程序员模式。Windows自带的计算器切到程序员模式能同时看十进制、十六进制、二进制还能做位运算排查效率比手算高一个数量级。第二条写涉及位运算的代码时注释里把位模式画出来。比如// 0b00001111 低4位掩码这样review的人和三个月后的自己都能秒懂。这个习惯我坚持了很多年省下的沟通成本难以估量。第三条不要迷信“这个值不可能溢出”。我见过太多溢出bug的事后发现出问题的值在理论上确实不会超范围但上游某个环节的异常数据把它推过了线。防御性编程在数值处理上永远不过时。第四条学习二进制最好的方式是读标准库的源码。比如看看语言标准库里的整数转字符串、哈希函数、随机数生成器是怎么用位运算的比看任何教程都来得实在。我当年就是靠读这些源码把位运算的直觉建立起来的。6. 从二进制出发的进阶方向把前面这些吃透之后二进制这块还有几个值得深入的方向。一个是位图bitmap的应用用二进制位来标记状态在海量数据去重、布隆过滤器、用户在线状态这类场景里非常高效。核心思路和权限系统一脉相承只是规模从32位扩展到任意长度。另一个是压缩算法里的二进制操作比如变长编码、位流读写理解了这些你就能明白为什么有些压缩格式解压快有些慢。还有一个方向是理解CPU的位操作指令。现代处理器对位运算有专门的优化比如统计二进制中1的个数的指令、找最高位的指令很多语言的标准库都暴露了对应的内建函数。在性能敏感的代码里用这些内建函数替代手写循环往往能带来数倍的提升。我做过一次字符串哈希的优化把手写的位混合逻辑换成内建函数后吞吐量提升了将近三倍。这些进阶方向有个共同点它们都建立在“把数值看成位的集合”这个视角之上。你不需要成为汇编专家但当你习惯用二进制的眼睛看代码时很多优化机会和潜在问题会自己浮现出来。我在实际项目里越来越体会到二进制基础扎实的人排查问题的速度和写出的代码质量确实会高出一个层次。这个差距在业务代码里可能不明显但一旦系统规模上去、性能要求变严就会迅速拉开。 
长河君 · 2026/11/2 8:38:54 · 阅读 1.2k 二进制基础：从补码、位运算到浮点数精度的实战指南
1. 为什么每个写代码的人都该把二进制当母语干了这么多年开发我越来越觉得二进制这东西就像空气——平时感觉不到它的存在可一旦出问题十有八九是它在背后捣鬼。你可能写过无数行代码用过各种高级语言但真正让你在排查线上事故时心里有底的往往是对二进制层面的理解深度。举个最常见的场景某天接口返回的数据莫名其妙多了个负号或者两个看起来相等的浮点数比较结果却是false再或者一个位运算把整个权限系统搞崩了——这些问题的根子基本都能追溯到二进制这个地基上。二进制基础知识听起来像是大学课本第一章的内容但它实际覆盖的范围远比大多数人想象的要广。从最底层的位与字节、原码反码补码的转换逻辑到整数的溢出行为、浮点数的精度陷阱再到位运算在权限控制、状态压缩、哈希计算中的实战应用这一整套东西构成了程序员理解计算机行为方式的底层框架。你可以不手写汇编但你得知道为什么0.1 0.2 ! 0.3你可以天天用框架但你得明白为什么一个int在某些场景下会突然变成负数。这篇内容适合谁看我的判断是三类人最需要第一类是刚入行不久、对计算机底层还停留在“知道有这回事”阶段的开发者补齐这块知识能让你后面学什么都快半拍第二类是工作几年但一直做上层业务、遇到底层问题就发怵的工程师把二进制捡起来能显著提升你排查疑难杂症的底气第三类是对性能敏感、想做优化但不知道从哪下手的同学位运算和二进制思维往往是性价比最高的优化切入点。下面我按自己带人、踩坑、复盘的经验把二进制这块从思路到实操完整拆一遍。2. 整体认知框架与学习路径拆解2.1 二进制到底在解决什么问题很多人学二进制的方式是背转换规则除2取余、乘2取整背完就完事了。这种方式的问题在于你记住的是操作步骤而不是它存在的理由。二进制在计算机里承担的核心角色其实就一个用两种稳定状态来表达一切信息。电路的通和断、电平的高和低、磁介质的两个方向这些物理现象天然只有两个稳定态所以用0和1来映射是最省事、最不容易出错的选择。理解了这个前提后面所有的设计就都顺了。为什么整数要用补码表示因为用补码可以把减法统一成加法硬件上只需要一套加法电路就能同时处理加减法省掉了专门的减法器。为什么浮点数会有精度问题因为二进制小数只能精确表示分母是2的幂的分数0.1在二进制里是无限循环小数存进有限位数的容器里必然被截断。这些“为什么”才是二进制知识的骨架转换规则只是皮肉。我在带新人的时候有个习惯不让他们先背转换方法而是先问一个问题——如果让你用只有两个刻度的尺子去量所有长度你会怎么设计这个问题能逼着人去想“表示范围”和“精度”的权衡而这恰恰是二进制所有设计的核心矛盾。想通了这个后面学原码反码补码、学浮点数的IEEE 754标准就都是在看别人怎么解这道题。2.2 学习路径的优先级排序二进制相关知识面很宽但不同内容的实战价值差别巨大。我按自己的经验给一个优先级排序你可以对照着查漏补缺。优先级知识模块实战出场频率建议投入P0补码与整数溢出极高几乎每周都会遇到相关bug必须吃透P0位运算的语义与常见套路极高权限、状态、优化都靠它必须吃透P1进制转换二/八/十/十六高调试和读配置时常用熟练即可P1浮点数精度与表示高涉及金额、科学计算必踩理解原理P2字节序大小端中跨平台通信和文件解析时遇到知道怎么排查P2位图与状态压缩中大数据量和性能优化场景掌握思路这个排序的逻辑很简单出场频率决定投入产出比。补码和位运算几乎贯穿所有代码浮点数精度问题在业务系统里迟早要撞上而字节序这类问题虽然不常遇到但一旦遇到就是硬骨头至少得知道排查方向。至于更深的内容比如位域、SIMD相关的二进制操作等前面这些吃透了再往上走不迟。2.3 一个容易被忽略的认知二进制思维比二进制知识更重要我见过不少人对补码转换倒背如流但写代码时依然会写出if (a - b 0)这种在溢出场景下会翻车的判断。问题不在于知识不够而在于没有形成二进制思维——也就是在写每一行涉及数值和位的代码时脑子里能自动浮现出它在内存里的样子。举个我自己的例子。早年做权限系统一开始用数据库存角色和权限的关联表查询时要join好几张表。后来改成用一个整数的不同二进制位表示不同权限判断权限就是一次按位与操作性能提升非常明显。这个改造的技术门槛其实很低难的是当时能不能想到“一个整数的32个位就是32个开关”这个视角。二进制思维的本质就是把“数值”和“位的集合”这两种视角自由切换的能力。培养这种思维没有捷径但有方法每次遇到数值相关的bug强迫自己把相关变量在内存里的二进制形式画出来。画上十几次你就会发现很多看似诡异的现象其实一目了然。下面几个章节我会结合具体场景把这种“画出来看”的方法贯穿进去。3. 核心概念深挖与关键细节解析3.1 补码为什么负数在计算机里长那样补码是二进制知识里最容易被教歪的部分。很多教材上来就是“取反加一”但不说为什么。我用一个生活化的类比来解释假设你有一个只能显示两位数的里程表从00到99转一圈回到00。现在你想表示“倒退1公里”怎么表示答案是99因为从99再往前拨一格就回到00效果和倒退1公里完全一样。补码就是这个思路——用“往前转一大圈”来表示“往后退一小步”。具体到8位整数范围是0到255。要表示-1就用255二进制11111111因为255加1会溢出回到0效果等同于-1加1等于0。所以负数的补码本质上就是“模2的n次方下的补数”。理解了这一点取反加一这个操作就有了来由对一个数取反相当于用全1去减它再加1正好凑成模运算下的补数。这个原理直接决定了一个实战中极其常见的坑整数溢出。8位有符号整数的范围是-128到127当你算127加1时二进制是01111111加00000001等于10000000按补码解读就是-128。这不是bug是设计使然。我在实际项目里遇到过最典型的一次某统计模块用int累加一个理论上不会超过21亿的计数结果某天数据量暴涨直接溢出成负数下游报表全乱。后来改成long并加了溢出检测才稳住。注意判断两个数相加是否溢出不要用结果去反推而要用符号位的变化来判断。同号相加结果变号就是溢出。这个判断方式在任何位宽下都成立。3.2 位运算的语义地图六个运算符各自的脾气位运算一共六个与、或、异或、取反、左移、右移。单看定义谁都会但真正用好需要知道每个运算符在实战中的“性格”。按位与的性格是“筛子”常用来做掩码提取和清零。比如从一个整数里取低8位就是x 0xFF。按位或|的性格是“开关合上”常用来置位。按位异或^的性格最特别它是“相同为0不同为1”所以有两个妙用一是翻转指定位二是利用a ^ a 0和a ^ 0 a来做“找出唯一出现一次的数”这类问题。取反~在实战中单独用得少更多是配合掩码使用。左移和右移需要特别注意有符号和无符号的区别。左移x n等价于乘以2的n次方但要注意高位溢出。右移则分算术右移和逻辑右移有符号数右移时高位补符号位算术右移无符号数右移时高位补0逻辑右移。这个区别在跨语言时尤其容易翻车比如Java的是算术右移是逻辑右移而Python的右移行为又和它们不同。运算符常见用途典型陷阱掩码提取、判断奇偶、清零掩码写错位导致误判|置位、合并标志与加法混用导致重复置位出错^翻转位、找唯一数、简单加密对自身异或清零的语义被误用~配合掩码构造有符号数取反后符号位变化快速乘2的幂溢出、负数左移的行为差异快速除2的幂有符号右移的舍入方向关于右移的舍入方向有个细节值得单独说算术右移对负数是向下取整比如-3右移1位是-2而不是-1。如果你用右移来实现“除以2”在负数场景下结果会和除法不一致。这个坑我在做分页计算时踩过页码为负的边界情况直接算出了错误的偏移量。3.3 浮点数精度问题不是bug是特性浮点数的二进制表示遵循IEEE 754标准核心思路是把一个数拆成符号位、指数位和尾数位三部分类似科学计数法。单精度float是1位符号、8位指数、23位尾数双精度double是1位符号、11位指数、52位尾数。尾数位决定了精度指数位决定了范围。精度问题的根源在于二进制只能精确表示形如“分母是2的幂”的分数。0.5、0.25、0.125这些都没问题但0.1在二进制里是无限循环小数存进23位或52位的尾数里必然被截断截断就产生误差。所以0.1 0.2在浮点数世界里不等于0.3而是等于0.30000000000000004。这不是哪个语言的问题是所有遵循IEEE 754的平台共同的行为。实战中处理金额时我的建议是坚决不用浮点数改用整数以最小货币单位存储比如以分为单位存金额或者用定点数、高精度库。如果非要用浮点数比较永远不要用而是判断两者差值是否小于一个足够小的阈值。这个阈值怎么选一般取业务精度要求的一半比如要求精确到小数点后两位阈值取0.005左右。提示浮点数的特殊值也值得记一下。NaN和任何数比较包括自己都返回false正无穷和负无穷有明确的运算规则。调试时看到NaN第一反应应该是去找0除以0或者无穷减无穷这类操作。3.4 字节序数据在内存里的排列方向字节序讲的是多字节数据在内存中的存放顺序。大端序是高字节存在低地址小端序是低字节存在低地址。比如整数0x12345678大端序在内存里是12 34 56 78小端序是78 56 34 12。x86架构是小端序网络传输协议通常规定用大端序所以做网络编程时经常需要做字节序转换。这个问题在日常业务开发里很少遇到但一旦涉及跨平台文件解析、网络协议实现、或者和硬件设备通信就是绕不过去的坎。我排查过一次数据解析错误现象是读出来的数值总是莫名其妙地大了很多倍最后发现是对方设备发的是大端序我方按小端序解析了。排查方法很简单把收到的原始字节按十六进制打印出来对照协议文档一看便知。判断本机字节序有个经典的小技巧定义一个16位整数1然后把它按字节读取如果第一个字节是1就是小端序是0就是大端序。这个技巧的原理就是利用了1在两种字节序下低字节位置的不同。4. 实操过程与核心环节落地4.1 手把手做一次进制转换的完整推演进制转换是二进制的基本功但我要讲的不是背规则而是建立“位权”的直觉。以十进制转二进制为例除2取余法的每一步其实都在回答一个问题这个数里包含多少个2的幂。比如把156转成二进制过程如下156除以2得78余0这个0就是最低位因为156是偶数不含2的0次方。78除以2得39余0第二位也是0。39除以2得19余1第三位是1。继续下去得到10011100。验证一下128加16加8加4等于156对应位正好是第7、4、3、2位为1其余为0完全吻合。反过来二进制转十进制就是把每个为1的位对应的2的幂加起来。这里有个提速技巧记住2的0到10次方的值1、2、4、8、16、32、64、128、256、512、1024大部分日常场景够用了。十六进制和二进制之间的转换更简单因为一位十六进制正好对应四位二进制直接分组替换即可这也是为什么调试时大家都爱看十六进制——它和二进制之间的转换不需要计算。4.2 用位运算实现一个权限系统这是位运算最经典的实战场景我把完整思路和代码走一遍。假设一个系统有读、写、删、管四个权限用整数的四个位表示READ 1 0 # 0001 WRITE 1 1 # 0010 DELETE 1 2 # 0100 ADMIN 1 3 # 1000 def grant(user_perm, perm): return user_perm | perm def revoke(user_perm, perm): return user_perm ~perm def check(user_perm, perm): return (user_perm perm) perm这段代码的关键在于三个操作的语义授权是“或”因为要把对应位合上回收是“与上取反”因为要把对应位清零而保留其他位检查是“与之后等于目标”因为要确认目标位全部为1。注意检查时不能写成user_perm perm直接判断真值因为如果perm包含多个位只要有一个位匹配结果就非零会误判。这个细节我在code review里见过不止一次。这个方案的优势不只是省存储更重要的是判断效率——一次位运算就能完成权限校验不需要查表或join。扩展到32位就是32种权限扩展到64位就是64种对于绝大多数系统绰绰有余。如果权限种类超过位宽再考虑分组或者换方案。4.3 整数溢出的检测与防御实操整数溢出的防御要分场景。对于业务代码最稳妥的做法是选用足够宽的整数类型并在关键计算处加检测。以32位有符号整数加法为例检测逻辑如下INT_MAX 2**31 - 1 INT_MIN -2**31 def safe_add(a, b): result a b if a 0 and b 0 and result 0: raise OverflowError(positive overflow) if a 0 and b 0 and result 0: raise OverflowError(negative overflow) return result检测的原理就是前面说的符号位变化两个正数相加结果变负或者两个负数相加结果变非负都是溢出。乘法的检测更复杂一些可以用除法反推或者用更大位宽的类型先算再判断是否超出范围。对于性能敏感的底层代码检测本身的开销可能不可接受这时候的策略是“设计上避免溢出”——比如限制输入范围、用无符号数做计数、或者用饱和运算代替回绕。选择哪种策略取决于业务对正确性和性能的权衡没有一刀切的答案。4.4 浮点数比较的正确姿势浮点数比较的实操要点我整理成一个对照表覆盖常见场景场景错误做法正确做法判断相等a babs(a - b) epsilon判断大于a ba b epsilon金额计算用float/double用整数分或高精度库累加求和直接循环累加用Kahan求和或排序后累加判断是否为0a 0abs(a) epsilonepsilon的选取要结合业务精度。有个经验法则如果数据量级在1左右epsilon取1e-9比较合适如果量级到1e6epsilon要相应放大到1e-3左右因为浮点数的绝对精度随量级增大而降低。这个规律来自浮点数的表示方式——尾数位数固定指数越大能表示的相邻两个数之间的间隔就越大。5. 常见问题排查与避坑经验实录5.1 那些年我踩过的二进制坑第一个坑是位运算的优先级。在C系语言里位运算的优先级低于比较运算所以x 1 0会被解析成x (1 0)结果永远是0。正确写法是(x 1) 0。这个坑的隐蔽性在于代码能编译能运行只是逻辑全错。我现在的习惯是位运算一律加括号不给优先级任何犯错的机会。第二个坑是有符号数的右移。前面提过算术右移对负数是向下取整我在做哈希分桶时用hash n来算桶索引结果负数哈希值算出来的桶索引偏了一位导致部分数据永远落不到正确的桶里。修复方法是对哈希值先取绝对值或者转成无符号再移位。第三个坑是十六进制字面量的符号问题。在某些语言里0xFFFFFFFF被当作有符号的-1而不是无符号的4294967295做比较时会出意外。处理方法是显式声明无符号类型或者用语言提供的无符号字面量语法。5.2 排查二进制相关问题的通用套路遇到疑似二进制层面的问题我有一套固定的排查流程按顺序走基本能定位先把相关数值按二进制或十六进制打印出来肉眼观察位的模式。很多问题在这一步就暴露了比如本该是正数的值最高位是1。确认数据类型的位宽和符号性。是8位还是32位有符号还是无符号这决定了同样的位模式会被解读成什么值。检查所有位运算的括号和优先级确认运算顺序符合预期。如果是跨系统问题检查字节序是否一致。如果是浮点数问题检查是否有精度损失或者特殊值参与运算。这套流程的价值在于把“猜”变成“看”。二进制问题的特点是现象诡异但原因明确只要能看到位的真实状态答案往往就在眼前。5.3 常见问题速查表现象可能原因排查方向正数突然变负数整数溢出或符号位误读检查位宽和运算结果最高位两个相等的浮点数比较为false浮点精度误差改用阈值比较权限判断总是通过检查逻辑写成了非零判断改为与掩码后等于掩码数据解析数值偏大很多倍字节序不一致打印原始字节对照协议位运算结果完全不符预期运算符优先级问题给所有位运算加括号移位结果和除法不一致负数算术右移的舍入方向确认是否需要逻辑右移5.4 几条压箱底的经验第一条调试二进制问题时善用计算器的程序员模式。Windows自带的计算器切到程序员模式能同时看十进制、十六进制、二进制还能做位运算排查效率比手算高一个数量级。第二条写涉及位运算的代码时注释里把位模式画出来。比如// 0b00001111 低4位掩码这样review的人和三个月后的自己都能秒懂。这个习惯我坚持了很多年省下的沟通成本难以估量。第三条不要迷信“这个值不可能溢出”。我见过太多溢出bug的事后发现出问题的值在理论上确实不会超范围但上游某个环节的异常数据把它推过了线。防御性编程在数值处理上永远不过时。第四条学习二进制最好的方式是读标准库的源码。比如看看语言标准库里的整数转字符串、哈希函数、随机数生成器是怎么用位运算的比看任何教程都来得实在。我当年就是靠读这些源码把位运算的直觉建立起来的。6. 从二进制出发的进阶方向把前面这些吃透之后二进制这块还有几个值得深入的方向。一个是位图bitmap的应用用二进制位来标记状态在海量数据去重、布隆过滤器、用户在线状态这类场景里非常高效。核心思路和权限系统一脉相承只是规模从32位扩展到任意长度。另一个是压缩算法里的二进制操作比如变长编码、位流读写理解了这些你就能明白为什么有些压缩格式解压快有些慢。还有一个方向是理解CPU的位操作指令。现代处理器对位运算有专门的优化比如统计二进制中1的个数的指令、找最高位的指令很多语言的标准库都暴露了对应的内建函数。在性能敏感的代码里用这些内建函数替代手写循环往往能带来数倍的提升。我做过一次字符串哈希的优化把手写的位混合逻辑换成内建函数后吞吐量提升了将近三倍。这些进阶方向有个共同点它们都建立在“把数值看成位的集合”这个视角之上。你不需要成为汇编专家但当你习惯用二进制的眼睛看代码时很多优化机会和潜在问题会自己浮现出来。我在实际项目里越来越体会到二进制基础扎实的人排查问题的速度和写出的代码质量确实会高出一个层次。这个差距在业务代码里可能不明显但一旦系统规模上去、性能要求变严就会迅速拉开。