补码加减法与位移运算：原理、溢出排查及工程避坑

我到现在都还记得第一次在纸上手算-5 3的二进制结果时把符号位单独拎出来算结果算出了-8。那次之后我才真正明白补码这套规则不是老师为了为难学生编出来的而是一个被工程约束逼出来的、非常漂亮的设计。后来带新人、做底层调试、看反汇编我发现凡是跟补码、加减法运算、位移运算打交道的地方出问题的姿势高度雷同要么是符号位处理不当要么是把算术右移和逻辑右移搞混要么是溢出判据用错。这篇就按我带人时讲的那套顺序从为什么讲到怎么算再到怎么排查把我踩过的坑和总结的校验方法都摊开说清楚。不管你是刚学计算机组成原理的学生还是要处理位运算的开发者看完应该都能自己动手算、动手验。1. 为什么补码是绕不开的那道坎1.1 从一次真实的算错数说起我第一次系统接触定点数表示是在做一个需要手工推导硬件行为的练习。当时的任务很朴素设计一个能做加法和减法的电路模块。我天真地以为加法一套电路、减法一套电路各做各的就行了。结果老师在黑板上写了个问题如果一台机器只有加法器你能做减法吗那一下把我问住了。后来想通了减法本质上可以变成加法a - b a (-b)。只要我能用一种方式把-b表示出来并且让加法器在相加时自动产生正确结果那减法器就完全不需要了。这个用一种方式表示负数的方案就是补码。它的价值不在于数学上更优美而在于硬件上更省钱——省掉一套减法逻辑、省掉处理负零的特殊分支、省掉比较符号再决定用加还是减的判断电路。理解了这一点后面所有的规则取反加一、符号位参与运算、丢弃最高进位就都不是死记硬背了它们全是这个总目标下的必然推论。1.2 原码的两个硬伤负零和减法电路先说原码也就是最符合人类直觉的表示法最高位当符号位0 表示正1 表示负剩下的位表示绝对值。8 位下5是0000 0101-5是1000 0101。看起来挺好但对电路来说有两个致命问题。第一个是零不唯一。8 位原码里0000 0000是01000 0000是-0。同一个数值有两个编码意味着每次判断是不是零都得比较两次或者额外做归一化。这在硬件上是实打实的额外逻辑而且在浮点数比较、循环终止条件这些场景里会埋雷。第二个更麻烦原码不能直接相加。你试试1 (-1)即0000 0001 1000 0001 1000 0010按原码读出来是-2。显然错了。原因是符号位被当成了数值位参与进位糊涂账。所以用原码做运算必须先把符号位摘出来、比较两个数的绝对值大小、决定结果符号、再用大的减小的——这一整套流程恰恰是你想避开的那个减法电路。绕了一圈回到原点。1.3 反码的折中方案与它的两个坑反码是一个中间方案正数的反码等于原码负数的反码是符号位保持 1数值位按位取反。-5的反码是1111 1010。这个方案让加法变得有点样子了1 (-1)变成0000 0001 1111 1110 1111 1111按反码读是-0。结果虽然等于零但是是负零你还得再处理一次。更别扭的是循环进位。反码加法有个规则叫端回进位如果最高位产生了进位要把它加回到最低位去。比如 4 位反码算-3 -21100 1101 1 1001把最高进位 1 加回最低位得到1010读出来是-5对了。但这个把进位从最高位搬到最低位的操作在硬件上意味着你要把进位输出绕回来接到进位输入形成一条反馈路径时序上就变长了。所以反码虽然解决了能不能直接加的问题却付出了额外的电路代价。1.4 补码的设计初衷用加法器干减法的活补码把反码的取反改成了取反加一这一步改动看着小效果却是决定性的零变得唯一了而且不需要循环进位。1 (-1)用补码算0000 0001 1111 1111 1 0000 0000把最高位的进位直接丢掉结果0000 0000就是零。干净利落没有负零不需要任何回补操作。那个被丢掉的进位不是丢了错误信息而是本来就应该丢——这一点我在第 3 章会用模运算把这个账算清楚。所以补码的三个特性你可以当成一个整体的设计目标来记零唯一省掉特殊判断、符号位可参与运算省掉分离逻辑、进位自然丢弃省掉循环进位电路。代价是负数在视觉上不直观需要转换才能看出真值。用一句话概括补码是用人类读起来费劲换来了机器算起来省事这笔买卖在硬件层面太划算了。2. 原码、反码、补码的转换实操手册2.1 正数三码合一的省心区正数是最省心的原码、反码、补码三者完全相同。以 8 位为例5三种表示都是0000 0101127都是0111 1111。唯一要留心的是最高位的边界。8 位有符号数里最高位是符号位所以正数最大只能到0111 1111也就是127。如果你想表示200那就得用 9 位以上或者改用无符号类型。我刚学的时候写过一个用 8 位存 200 的补码的练习怎么算都得出负数卡了半小时才反应过来8 位表示不了 200 的正数1100 1000这个编码被分配给了-56。所以位数决定了范围范围决定了你能表示什么这个顺序不能倒过来想。另外提一句补码的1000 0000是个特殊编码。按原码规则它应该是负零但补码里没有负零这个位置被征用去表示-128了。这也是为什么 8 位补码的范围是-128 ~ 127负数比正数多一个。多出来的那一个正是零唯一化留下的名额。2.2 负数取反加一的完整流程与末位进1的细节负数转补码标准三步写出绝对值的原码 → 全部位按位取反 → 末位加 1。以 8 位-5为例步骤二进制说明绝对值原码0000 0101先不管符号写 5按位取反1111 1010得到反码符号位也一起取反末位加 11111 1011得到补码注意这里有个容易搞错的点按位取反是包括符号位在内的全部位取反不是只取反数值位。如果你只取反数值位-5会得到1000 1010那是反码的写法不是补码。这一步写反了后面全错。关于热搜里常见的负数补码末位进1我想多说两句因为这里的进位经常被算错。所谓末位加 1是从最低位开始加遇到0变1就停遇到1变0并向前进位可能连续进位一路传到符号位。举两个例子-1绝对值原码0000 0001→ 取反1111 1110→ 加 1最低位0变1得1111 1111。这是一个只进一位的情况。-128绝对值原码是1000 00008 位下 128 已经超范围了这里用 8 位原码形式来推取反得0111 1111加 1 之后连续进位一路变成1000 0000。这正是补码里-128的编码。我个人的经验是遇到末位加 1不要心算跳步老老实实在纸上写出二进制串从右往左一位一位处理进位。尤其是连续进位比如0111 1111 1这种情况跳步十有八九会漏掉进位链。写过几次之后你会发现1111 1111-1、1000 0000-128、1111 1000-8这几个编码会形成肌肉记忆。2.3 由补码反推原码的两种方法给你一个补码怎么知道它代表几这也是热搜词里补码求原码方法指向的问题。方法有两个我推荐第二个。方法一逆运算。补码减 1 得反码再全部取反得原码。比如1111 1011减 1 得1111 1010全部取反得0000 0101也就是绝对值 5符号位看补码最高位是 1所以是-5。方法二从右往左找第一个 1。规则是保留最右边的第一个 1 以及它右边的所有位不变左边的所有位含符号位全部取反。用同样的1111 1011试从右往左数第一个 1 在最右端第 0 位它右边的位没有所以保留1左边所有位1111 101取反变成0000 010拼起来0000 0101读出来是 5最高位看原补码是 1所以真值是-5。再换个例子验证方法二补码1110 1100。从右往左第 0 位是 0第 1 位是 0第 2 位是 1这是第一个 1。保留第 2 位及其右边100左边1110 1取反得0001 0拼起来0001 0100也就是 20所以真值是-20。验算一下1110 1100无符号值是 236236 - 256 -20对上了。提示方法二在口算时更快因为它只需要在最低位附近做一次短距离扫描不用对整个数做减法。但它的正确性依赖于取反加一和加一取反的等价性如果你对原理不熟先用方法一验算两三遍建立信心后再切到方法二。2.4 位数扩展符号扩展为什么必须补符号位实际写代码时经常要把short提升成int或者把 8 位补码扩展到 16 位这时候要遵守符号扩展规则正数高位补 0负数高位补 1。为什么因为补码的数值是相对于 2 的幂次定义的。8 位的-5是1111 1011代表256 - 5 251这个模 256 的补数。要扩展到 16 位它必须变成65536 - 5 65531也就是1111 1111 1111 1011。你看高 8 位全是 1。如果你偷懒补 0变成0000 0000 1111 1011那就成了正数251数值完全变了。这个坑我在做协议解析时踩过从串口收到的字节流里取一个有符号字段忘了做符号扩展就直接当正数处理结果温度读数在零下的时候全变成了 200 多排查了半天才发现是这里。所以我现在的习惯是只要涉及有符号数的类型提升、移位、拼接先问自己一句这步操作对高位做了什么。3. 补码加减法运算的核心机制3.1 加法符号位直接参与不用特殊处理补码加法最大的便利就是符号位不用单独拎出来直接跟数值位一起加。因为补码本身就是设计成可以整体当无符号数来加的。以 8 位算-5 3为例1111 1011 (-5 的补码) 0000 0011 (3 的补码) ----------- 1 1111 1110最高位产生进位1把它丢掉剩下1111 1110。按第 2.3 节的方法读从右往左第一个 1 在第 1 位保留10左边1111 11取反得0000 00拼成0000 0010也就是 2符号位为 1真值-2。验算-5 3 -2正确。再看一个同符号相加的例子-5 (-3)1111 1011 (-5) 1111 1101 (-3) ----------- 1 1111 1000丢进位得1111 1000。读一下从右往左第一个 1 在第 3 位保留1000左边1111取反得0000拼成0000 1000即 8符号位 1真值-8。验算-5 -3 -8正确。我发现很多人卡在为什么进位要丢掉这个点上觉得是在作弊。其实不是丢掉进位恰恰是补码能工作的原因第 3.3 节会把账算清楚。3.2 减法转成加负数一步到位减法不需要任何新规则把减数取相反数补码层面就是取反加一再相加就行。这里的取反加一是在补码本身上操作的不是先转回原码。算7 - 54 位为例。7的补码是01115的补码是0101。求-5对0101全部取反得1010加 1 得1011。然后0111 10110111 1011 ------ 1 0010丢进位得0010即 2。正确。这里有个极容易出的错求相反数时是对补码取反加一而不是对原码。有人习惯先转成原码加个负号再转回补码中间多转两次出错概率翻倍。我建议直接用补码取反加一 相反数这条规则因为它本身就是补码的一条性质可以直接用。顺带说一个我在调试中常用的技巧判断两个补码是不是互为相反数可以用两数相加是否为1000...0来快速检查。因为x (-x)在补码里等于1000...0最高位进位丢掉后得全零。这个检查在排查符号错误时特别好用。3.3 模运算视角丢掉的进位去哪了这是我认为最该讲清楚的一节因为它能一次性解释为什么要丢进位为什么会有溢出为什么补码能自动处理符号。把 n 位补码看成一个模 2^n 的时钟。8 位就是模 256 的时钟1111 1111代表 255再往前走一格就绕回0000 00000。在这个时钟上负数-k的表示就是2^n - k。比如-5就是256 - 5 251二进制正是1111 1011。现在看-5 3在时钟上就是251 3 254。因为 254 落在128 ~ 255这个范围对应负数区读出来是254 - 256 -2。完美不需要任何特殊处理。再看1 (-1)1 255 256。但时钟只有 256 个刻度0~255256 正好绕回 0。所以丢掉进位在数学上等价于对 2^n 取模。这不是信息丢失而是本来就在模运算的框架里结果早就被定义为模 2^n 的值了。想明白这一点你就能理解为什么补码的加减法能无脑相加因为在这个模系里加法和减法本来就是同一种运算减去 b 等于加上 b 在模 2^n 下的加法逆元。硬件只需要一个加法器不需要任何判断和分支。注意模运算视角同时解释了溢出的本质——当真实结果的绝对值超出了[-2^(n-1), 2^(n-1)-1]这个范围时结果绕过了时钟的接缝落到了错误的位置。所以溢出不是算错了而是结果超出了可表示范围。这个区别在调试时很重要。3.4 溢出判断的三种判据与选择溢出是补码运算里最需要小心的地方因为它不会报错只会给你一个看起来合理的错答案。我整理三种常用判据判据具体规则适用场景符号位法两正得负 正溢出两负得正 负溢出一正一负不可能溢出手工演算最快进位异或法最高位进位 Cs 与次高位进位 C1 不同Cs XOR C1 1则溢出硬件实现最省双符号位法用两位符号位结果符号为 01 是正溢出10 是负溢出教学演示、理解本质符号位法最好记因为直觉上说得通同号相加结果符号变了说明数值部分把符号位给顶变了。比如 8 位100 1000110 0100 (100) 0110 0100 (100) ----------- 1100 1000两个正数相加结果最高位变成 1也就是被读成了负数-56。明显的正溢出正确结果应该是 200超出 8 位有符号范围。进位异或法适合看硬件行为。还是这个例子次高位第 6 位相加110并产生进位1最高位第 7 位相加0011没产生进位。Cs 0C1 1异或得 1判溢出。一正一负相加永远不会溢出这是我最常用的一个快速排除条件。因为两数异号时结果的绝对值一定不超过较大的那个数的绝对值不可能冲出范围。调试时如果你发现了溢出先看一眼操作数符号如果是一正一负那百分百不是溢出问题得去别处找原因。4. 位移运算原理左移好懂右移才是真难点4.1 左移逻辑左移与算术左移在数值上没区别左移就是整体往左挪低位补 0高位溢出丢弃。8 位0000 01015左移 1 位得0000 101010相当于乘 2。负数也一样-5的补码1111 1011左移 1 位得1111 0110。读一下1111 0110从右往左第一个 1 在第 1 位保留10左边1111 11取反得0000 00拼成0000 1010 10符号位 1真值-10。正好是-5 × 2。有意思的地方在于虽然名字上有逻辑左移和算术左移之分但在补码体系下两者的实际行为是一样的——都是低位补 0高位丢弃。区别只在概念层面逻辑左移把数当无符号位串看算术左移把数当有符号数看。但只要都是补 0数值结果就一致。这也是为什么很多架构里干脆只提供一种左移指令。不过要注意溢出的边界。100 × 2应该是 200超出 8 位有符号范围。0110 0100 1 1100 1000读出来是-56。所以左移不是无条件等于乘 2超出范围就会绕圈。我在做位运算优化时有一条铁律用左移替代乘法之前先确认结果不会溢出否则宁可让编译器去处理。4.2 右移的两种语义补0还是补1右移才是真正容易出错的地方因为它有两种截然不同的补位规则逻辑右移高位一律补 0把数当无符号位串处理。算术右移高位补符号位的值正数补 0负数补 1。看 8 位下的-8补码是1111 1000操作结果真值含义算术右移 1 位1111 1100-4数值除以 2逻辑右移 1 位0111 1100124位串整体右挪同样是-8 1两种语义给出-4和124差了十万八千里。这就是为什么很多语言要区分和Java 里是算术右移是逻辑右移C 和 C 里对无符号数执行逻辑右移对有符号数是实现定义行为虽然现实中几乎都是算术右移。你在阅读旧代码或者做跨平台移植时这一点必须查清楚。4.3 负数右移为什么补1从数值意义反推很多人问我为什么负数右移要补 1我的回答是不补 1 就不是除以 2 了。设想-8 1111 1000我们想右移一位得到-4 1111 1100。对比一下-8: 1111 1000 -4: 1111 1100从-8到-4最高位要保持 1下面补进去的位也得是 11111 1000的最低位本来就是 0移位后要补的其实是紧邻符号位的那一位。如果补 0你得到的是0111 1100符号变了数值也完全不对。更本质的解释还是模运算。负数在补码里是2^n - |x|。-8是256 - 8 248。要算-4是256 - 4 252。从 248 到 252 是怎么变的248是1111 1000252是1111 1100也就是高位补 1 的右移。所以算术右移补符号位本质上是让这个模系里的数值关系保持正确。这里有个我踩过的坑值得单独说算术右移不是向零取整而是向下取整。-5 1等于多少1111 1011 1 1111 1101读出来是-3。但-5 / 2在 C、Java 这些语言里是-2向零截断。差了一个。这个差异在写用移位代替除法做优化的时候会咬人。我做过一个统计逻辑需要把计数值除以 2 取整图快写了x 1结果负数样本全部偏移 1统计结果偏了 0.5 个单位的量级。后来统一加了个修正如果要对负数做向零取整的除 2得写(x (x 31 1)) 1或者干脆老老实实写/ 2让编译器去优化。4.4 移位替代乘除法的边界条件移位替代乘除法是常见的优化手段但有四个边界条件必须记住第一只能替代 2 的整数次幂。左移 k 位等于乘2^k右移 k 位等于除以2^k向下取整。乘 3、乘 10 这些用移位做就需要拆成x 1 x之类的组合反而可能不如直接乘快而且可读性差。第二移位位数不能超过或等于数据宽度。这一点在不同语言里行为很不一样。C 语言里对 32 位整数移 32 位是未定义行为Java 里会先把移位数对 32 取模x 32等于x 0也就是原值Python 因为是任意精度整数x 100会真的给你一个巨大的数。这个差异在移植代码时很容易出事故。第三负数左移可能触发有符号溢出是未定义行为。C 标准里左移一个负数或者左移结果超出有符号类型范围都属于 UB。虽然大多数编译器按补码规则老实处理但开了优化之后可能出现你意想不到的结果。稳妥做法是先用无符号类型做移位再转回有符号。第四算术右移是实现定义行为不要当成标准保证。如果你的代码需要在不同编译器、不同平台上都保持行为一致要么用无符号类型配逻辑右移再自己做符号处理要么用语言提供的明确接口比如 Java 的。5. 实操案例手算 代码双重验证5.1 一组完整的 8 位演算光讲规则容易飘我带你完整走一遍。题目用 8 位补码计算-37 - 45并判断是否溢出。第一步求两个数的补码。37的原码0010 0101取反1101 1010加 1 得1101 1011所以-37的补码是1101 1011。45的原码0010 1101取反1101 0010加 1 得1101 0011所以-45的补码是1101 0011。第二步把减法转成加法。-37 - 45 -37 (-45)。两个操作数都是负数符合同号相加需要判溢出的条件。第三步相加。1101 1011 (-37) 1101 0011 (-45) ----------- 1 1010 1110最高位产生进位丢掉得1010 1110。第四步读结果。符号位是 1负数。用方法二求绝对值从右往左第一个 1 在第 1 位1010 1110最低位是 0第 1 位是 1保留10左边1010 11取反得0101 00拼成0101 0010 82。所以结果是-82。第五步验算。-37 - 45 -82正确。范围检查-82在-128 ~ 127内不溢出。整条链路走下来你会发现真正需要动脑的只有求补码和读补码两步中间那个加法反而是最机械的。5.2 用代码验证你的手算结果手算完一定要验证这是我的习惯。下面三段代码覆盖三种常见语言的行为差异你可以直接跑#include stdio.h int main(void) { signed char a -37, b -45; signed char s a b; printf(a %d, b %d, sum %d\n, a, b, s); printf(a 的 bits(无符号视角) %u\n, (unsigned char)a); printf(b 的 bits(无符号视角) %u\n, (unsigned char)b); signed char x -5; printf(-5 1 %d\n, x 1); printf(-5 / 2 %d\n, x / 2); return 0; }a -37, b -45, sum -82 a 的 bits(无符号视角) 219 b 的 bits(无符号视角) 211 -5 1 -3 -5 / 2 -2219验算一下256 - 37 219二进制1101 1011跟手算一致。211 256 - 45二进制1101 0011也对。最后两行则印证了 4.3 节说的算术右移是向下取整整数除法是向零取整。x -5 print(x 1) # -3Python 的 是算术右移 print(x // 2) # -3地板除也是向下取整 print(int(x / 2)) # -2先转浮点再截断向零取整 print(bin(-37 0xFF)) # 0b11011011看补码位模式public class BitDemo { public static void main(String[] args) { int a -5; System.out.println(a 1); // -3算术右移 System.out.println(a 1); // 2147483645逻辑右移 System.out.println(a / 2); // -2向零取整 System.out.println(Integer.toBinaryString(a)); // 11111111111111111111111111111011 System.out.println(Integer.toBinaryString(a 1)); // 1111111111111111111111111111101 } }Java 那行的输出2147483645特别有教学价值-5的 32 位补码是11111111 11111111 11111111 11111011逻辑右移一位后变成01111111 11111111 11111111 11111101最高位变 0整个数从负数变成了一个接近2^31的大正数。这就是逻辑右移和算术右移最直观的差别。5.3 有符号与无符号混用的现场事故我遇到过一个非常典型的 bug值得单独拎出来讲。代码大致是unsigned int len 10; int n -1; if (n len) { // 期望进入这里 }结果这个判断是 false。原因是 C 语言里int和unsigned int比较时int会被隐式转换成unsigned int-1的补码1111...1111被当成无符号数读变成了4294967295当然不小于 10。这个坑的根源正是补码同一个位模式按有符号读是-1按无符号读是 4294967295。补码本身不带类型信息类型是编译器贴上去的标签。所以我现在的习惯是只要代码里同时出现有符号和无符号第一反应就是去看类型转换规则。开-Wall -Wextra-Wsign-compare这类警告一定要当错误处理它们是免费的 bug 探测器。6. 常见问题与排查技巧实录6.1 典型错误速查表带了这么些年我发现大家犯的错高度集中在下面这几个位置。整理成表出问题的时候从上往下逐条对现象最可能的原因快速验证方法两数相加结果符号不对溢出检查操作数是否同号负数转补码算出来不对取反时漏了符号位或加 1 时进位算错用256 - 绝对值反推编码从补码读真值读错忘了符号位也要参与取反用从右往左第一个 1法复算右移结果是个巨大的正数用了逻辑右移处理负数确认用的是还是右移代替除法后有偏差算术右移是向下取整不是向零取整拿负数试一下 -5/2类型提升后数值突变忘了符号扩展高位补了 0打印十六进制看高位无符号比较结果反直觉有符号被隐式转成了无符号查类型转换和编译警告移位结果和预期不符移位位数超过数据宽度行为未定义或被取模确认移位数小于位宽6.2 排查思路从二进制逐位对齐开始我调试位运算问题的固定流程是四步基本能覆盖九成情况。第一步把位模式打出来。别用十进制看直接转成二进制或十六进制把每个操作数的位模式写在一张纸上或者打印出来。人眼对十进制不敏感但对位模式的对齐很敏感一写出来问题往往自己就跳出来了。第二步逐位对齐做加法标出每一位的进位。很多人算错是进位漏了。你在每一位下面标一个小数字记录进位输入算完再核对一遍。这个方法笨但它能让你精确定位到哪一位开始不对。第三步用模运算做校验。把所有数转成模 2^n 下的非负代表负数就加 2^n做普通整数运算再取模 2^n最后按符号位解读。这个路径绕开了补码的所有技巧纯机械操作适合用来交叉验证。第四步写代码验证。手算和代码对不上时先怀疑手算。我统计过自己的出错率手算错的概率远高于代码。用 C 或者 Python 跑一遍把中间结果都打印出来比在脑子里较劲高效得多。6.3 独家避坑技巧最后分享几条我攒下来的经验都是常规教材里不太会写的。技巧一用256 减绝对值快速写负数补码。8 位下-x的补码等于256 - x。-37就是256 - 37 219 1101 1011。心算比取反加一快而且不容易在进位链上出错。位数换成 16 位就是65536 - x。这个方法在需要快速写出编码的场合特别顺手。技巧二判断溢出先看符号。一正一负永不溢出直接排除。剩下的情况里把两数绝对值相加跟2^(n-1) - 1正溢出或2^(n-1)负溢出比一下比逐位分析进位快得多。技巧三-1的补码是所有位全 1这个锚点要记住。8 位是1111 111132 位是 32 个 1。看到全 1 就知道是-1。类似的锚点还有-128是1000 0000、-2是1111 1110。记住几个常用值能大幅提升读位模式的直觉。技巧四负数右移用先加偏移再移处理取整方向。如果业务需要向零取整的除 2可以用(x 0 ? x 1 : x) 1这类修正或者干脆用除法。别为了省一个时钟周期去赌编译器的行为。技巧五涉及位运算的代码注释里写上二进制示例。我在团队里推行的一个约定是任何涉及掩码、移位、符号处理的代码注释里必须带一个具体的二进制例子。这个约定让我们后来联调时省了非常多时间因为后来者不用再从头推一遍位模式。技巧六测试用例一定要覆盖边界。我固定会测这几个值0、1、-1、最大值、最小值以及刚好不溢出和刚好溢出的一对。补码的奇奇怪怪的行为全部集中在边界上中间值的表现通常都很正常。我个人的体会是补码这套东西最大的价值不在考试而在于它给了你一个看位模式就知道数值行为的能力。当你习惯用补码的视角去看一个二进制串很多过去觉得莫名其妙的现象——为什么负数右移会变大、为什么无符号比较会反直觉、为什么溢出之后结果会跳到另一头——都会变得理所当然。这个视角一旦建立起来再去读汇编、做协议解析、写位运算优化心里就有底了。