企业官网建设流程全解析

我到现在都还记得，第一次在纸上手算-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是+0，1000 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 + -2：1100 + 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 0101，+127都是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为例：

注意这里有个容易搞错的点："按位取反"是包括符号位在内的全部位取反，不是只取反数值位。如果你只取反数值位，-5会得到1000 1010，那是反码的写法，不是补码。这一步写反了，后面全错。

关于热搜里常见的"负数补码末位进1"，我想多说两句，因为这里的进位经常被算错。所谓"末位加 1"，是从最低位开始加，遇到0变1就停，遇到1变0并向前进位，可能连续进位一路传到符号位。举两个例子：

• -1：绝对值原码0000 0001→ 取反1111 1110→ 加 1，最低位0变1，得1111 1111。这是一个"只进一位"的情况。
• -128：绝对值原码是1000 0000（8 位下 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无符号值是 236，236 - 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 - 5，4 位为例。7的补码是0111，5的补码是0101。求-5：对0101全部取反得1010，加 1 得1011。然后0111 + 1011：

0111 + 1011 ------ 1 0010

丢进位得0010，即 2。正确。

这里有个极容易出的错：求相反数时，是对"补码"取反加一，而不是对"原码"。有人习惯先转成原码，加个负号，再转回补码，中间多转两次，出错概率翻倍。我建议直接用"补码取反加一 = 相反数"这条规则，因为它本身就是补码的一条性质，可以直接用。

顺带说一个我在调试中常用的技巧：判断两个补码是不是互为相反数，可以用"两数相加是否为1000...0"来快速检查。因为x + (-x)在补码里等于1000...0（最高位进位丢掉后得全零）。这个检查在排查符号错误时特别好用。

3.3 模运算视角：丢掉的进位去哪了

这是我认为最该讲清楚的一节，因为它能一次性解释"为什么要丢进位""为什么会有溢出""为什么补码能自动处理符号"。

把 n 位补码看成一个模 2^n 的时钟。8 位就是模 256 的时钟，1111 1111代表 255，再往前走一格就绕回0000 0000（0）。在这个时钟上，负数-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~255），256 正好绕回 0。所以"丢掉进位"在数学上等价于对 2^n 取模。这不是信息丢失，而是本来就在模运算的框架里，结果早就被定义为模 2^n 的值了。

想明白这一点，你就能理解为什么补码的加减法能"无脑相加"：因为在这个模系里，加法和减法本来就是同一种运算，减去 b 等于加上 b 在模 2^n 下的加法逆元。硬件只需要一个加法器，不需要任何判断和分支。

注意：模运算视角同时解释了溢出的本质——当真实结果的绝对值超出了[-2^(n-1), 2^(n-1)-1]这个范围时，结果"绕"过了时钟的接缝，落到了错误的位置。所以溢出不是"算错了"，而是"结果超出了可表示范围"。这个区别在调试时很重要。

3.4 溢出判断的三种判据与选择

溢出是补码运算里最需要小心的地方，因为它不会报错，只会给你一个看起来合理的错答案。我整理三种常用判据：

符号位法最好记，因为直觉上说得通：同号相加，结果符号变了，说明数值部分把符号位给"顶"变了。比如 8 位100 + 100：

0110 0100 (100) + 0110 0100 (100) ----------- 1100 1000

两个正数相加，结果最高位变成 1，也就是被读成了负数-56。明显的正溢出，正确结果应该是 200，超出 8 位有符号范围。

进位异或法适合看硬件行为。还是这个例子，次高位（第 6 位）相加1+1=0并产生进位1，最高位（第 7 位）相加0+0+1=1没产生进位。Cs = 0，C1 = 1，异或得 1，判溢出。

一正一负相加永远不会溢出，这是我最常用的一个快速排除条件。因为两数异号时，结果的绝对值一定不超过较大的那个数的绝对值，不可能冲出范围。调试时如果你发现了溢出，先看一眼操作数符号：如果是一正一负，那百分百不是溢出问题，得去别处找原因。

4. 位移运算原理：左移好懂，右移才是真难点

4.1 左移：逻辑左移与算术左移在数值上没区别

左移就是整体往左挪，低位补 0，高位溢出丢弃。8 位0000 0101（5）左移 1 位得0000 1010（10），相当于乘 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：

同样是-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，下面补进去的位也得是 1（1111 1000的最低位本来就是 0，移位后要补的其实是紧邻符号位的那一位）。如果补 0，你得到的是0111 1100，符号变了，数值也完全不对。

更本质的解释还是模运算。负数在补码里是2^n - |x|。-8是256 - 8 = 248。要算-4，是256 - 4 = 252。从 248 到 252 是怎么变的？248是1111 1000，252是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 = -2

219验算一下：256 - 37 = 219，二进制1101 1011，跟手算一致。211 = 256 - 45，二进制1101 0011，也对。最后两行则印证了 4.3 节说的"算术右移是向下取整，整数除法是向零取整"。

x = -5 print(x >> 1) # -3，Python 的 >> 是算术右移 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 典型错误速查表

带了这么些年，我发现大家犯的错高度集中在下面这几个位置。整理成表，出问题的时候从上往下逐条对：

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 1111，32 位是 32 个 1。看到全 1 就知道是-1。类似的锚点还有-128是1000 0000、-2是1111 1110。记住几个常用值，能大幅提升读位模式的直觉。

技巧四：负数右移用"先加偏移再移"处理取整方向。如果业务需要向零取整的除 2，可以用(x < 0 ? x + 1 : x) >> 1这类修正，或者干脆用除法。别为了省一个时钟周期去赌编译器的行为。

技巧五：涉及位运算的代码，注释里写上二进制示例。我在团队里推行的一个约定是：任何涉及掩码、移位、符号处理的代码，注释里必须带一个具体的二进制例子。这个约定让我们后来联调时省了非常多时间，因为后来者不用再从头推一遍位模式。

技巧六：测试用例一定要覆盖边界。我固定会测这几个值：0、1、-1、最大值、最小值，以及"刚好不溢出"和"刚好溢出"的一对。补码的奇奇怪怪的行为全部集中在边界上，中间值的表现通常都很正常。

我个人的体会是，补码这套东西最大的价值不在考试，而在于它给了你一个"看位模式就知道数值行为"的能力。当你习惯用补码的视角去看一个二进制串，很多过去觉得莫名其妙的现象——为什么负数右移会变大、为什么无符号比较会反直觉、为什么溢出之后结果会跳到另一头——都会变得理所当然。这个视角一旦建立起来，再去读汇编、做协议解析、写位运算优化，心里就有底了。