整数在计算机中如何表示？原码反码补码详解与溢出陷阱

1. 从二进制开始：为什么计算机只认0和1

先说一个我早年调试时遇到的场景。当时手头有个嵌入式项目，需要把传感器读到的温度值上报给上位机，温度可能是负数。我用一个int变量存了数据，然后用串口打印出来，一切正常。可当我把它包装成协议帧、按字节拆开发送时，上位机收到的数据完全对不上。排查了半天，最后发现是整数在内存里的表示方式出了问题——负数不是我想当然的“符号位加数值位”。

这个场景，几乎所有写过底层代码、做过协议解析、处理过二进制数据的人多少都撞见过。而它背后，就是“整数在计算机中到底怎么表示”这件基础到不能再基础的事。

先看最底层的问题：为什么计算机非要用二进制？这不是拍脑袋定的，而是物理实现决定的。晶体管只有两种稳定状态——导通和截止，对应电压的高和低。你当然可以用不同的电压档位来表示十进制里的0到9，但问题在于：电压会漂移、会有噪声、会有干扰。档位越多，区分度越低，误判概率越高。两个状态之间的分辨，是工程上最可靠、最抗干扰的方案。所以“计算机归根结底都是二进制”这句话，不是规定出来的，是被物理世界逼出来的。

有了二进制，就有了“位”（bit）这个概念。一位只能表示0或1，8位组成一个字节（byte），这是绝大多数现代计算机寻址的最小单位。而“字长”决定了一次能处理多少位，32位系统一次处理32个bit，64位系统一次处理64个bit。字长还决定了一个重要的东西：单个整数最多能占多少位。在一个32位系统里，一个int最长就是32位，超过这个位数就装不下了。

这里有个容易被忽略的点：同一个二进制串，不同解释方式会得到完全不同的数值。11111111 11111111 11111111 11111111这32位，如果你把它当无符号整数，它是4294967295；如果当有符号整数，它在补码表示下是-1。同一个内存内容，含义取决于你“怎么看”它。这也是为什么协议解析时，收发双方必须约定清楚数据类型——你说它是uint32_t，我说它是int32_t，同一个字节流能差出四十多亿。

2. 要表示负数，先说说原码和反码的困境

有了二进制基础，下一个问题接踵而至：负数怎么表示？数学课本里写的是“-5”，但计算机里没有负号这个符号，只有0和1。你必须在有限的位模式里，自己定义一套规则来编码负号。

最初的思路很直接：拿一位出来当符号位，剩下的是数值位。规定最高位是0表示正，是1表示负。于是：

• 0000 0101 表示 +5
• 1000 0101 表示 -5

这套方案叫原码。看起来非常直观，但它有两个致命问题。

第一个问题：加减法电路会变得非常复杂。你算5 + (-5)，不能像十进制那样直接对位相加完事。你得先判断两个数的符号，是同号还是异号，同号就直接加，异号就要比较绝对值大小，拿大数减小数，最后符号跟着绝对值大的走。这已经不是“加法器”能搞定的事了，你得额外设计一套“判断符号-比较大小-调整结果”的逻辑。在底层电路里，多一个步骤，就多一堆晶体管，多一份延迟，多一种出错的可能。

第二个问题：“0”有两种表示。0000 0000是+0，1000 0000是-0。你说+0和-0是同一个数吧，它们的二进制模式却不一样。程序里判断“a == 0”，你得分情况讨论a的原码是全零还是符号位为1后面全零。虽然通过额外逻辑也能处理，但总归是别扭。

为了解决原码的减法复杂问题，有人想出了反码。反码的规则是：正数不变，负数等于对应正数按位取反。还是拿5来举例：

• +5 的反码：0000 0101
• -5 的反码：1111 1010

反码的好处是，减法可以转换成加法来做，不用再搞一套“判断符号、比较大小”的逻辑。但反码也有个新麻烦：计算进位时可能要多加一次。比如算1 + (-1)，1的反码是0000 0001，-1的反码是1111 1110，相加得1111 1111，这是-0，结果倒是对的。但如果算1 + (-2)，1的0000 0001加-2的1111 1101，得到1111 1110，这看起来是-1，但最后一位的进位丢掉了，实际结果应该是-1，误打误撞算对了。可有些情况下进位丢不得，比如1 + (-1)如果最高位进位被丢掉，你就得把进位的1加回到最低位，这叫“循环进位”。多一次回加，又给电路增加了复杂度。

而且反码依然没有解决±0的问题：1111 1111是-0，0000 0000是+0。

原码和反码的困境总结起来就是一句话：它们都能表示负数，但要么加法电路复杂，要么存在±0的歧义，要么两者都有。如果你只是学理论，这些都不是死局，多加逻辑就能补。但如果目标是设计一台简单、高效、可靠的计算机，你需要一种更自洽的表示法。

3. 补码：看着绕，其实是加法电路的终极答案

补码的定义，教科书里写得很简单：正数的补码等于它本身，负数的补码等于对应正数按位取反再加1。比如+5的补码是0000 0101，-5的补码就是0000 0101取反得1111 1010，再加1得1111 1011。

但如果你只是背下“取反加一”这个操作，而不理解它背后的道理，遇到复杂的位操作题还是会懵。我换个角度讲。

先引入一个概念：模（modulo）。所谓模，就是一个计量系统的最大容量。钟表就是一个典型的模12系统：11点过了1个小时是12点，时钟显示为0点（12点）。在模12系统里，-1和11是等价的，因为减1小时和加11小时，指针最终停在同一个位置。

计算机里的整数也可以理解成模系统。一个8位的整数，能表示256种组合，它的模就是256。在这个模256的系统中，“减1”和“加255”是等价的，因为从任何一个数出发，减1和加255得到的结果对256取模之后是一样的。

那-1在8位里怎么表示？正好等于256 + (-1) = 255，也就是1111 1111。这个数正好是0取反（1111 1111），不需要加1。那-2呢？256 + (-2) = 254，二进制是1111 1110，这个数是0000 0010取反（1111 1101）再加1得到的。规律通了：负数的补码，本质上是“它加上模得到的那个等价正数”的二进制形式。

所以补码的精髓可以这样理解：它把减法这种操作，整个折叠进了“模”的循环里。有了补码，减一个数就等于加上它的补码，电路上完全用加法器搞定，不需要任何额外的符号判断逻辑。原码和反码折腾半天解决不了的事，补码直接绕过去了。

补码的不对称性也值得提一下。8位补码能表示的范围是-128到127，负数比正数多一个。为什么？因为补码里最高位为1就代表负数，1000 0000也就是128，在模256系统里128是-128的另一种写法。正数里没有对应的128，因为+128已经超出了127的容量。这个-128是个特殊值，取反加一还是它自己，对不上“正数取反加一”的直觉。如果哪天你在调试时发现一个int8_t变量打印出-128，不用怀疑算错了，它在补码里就是合法的。

补码还有一个非常实用的性质：符号扩展。把一个8位的有符号数扩展成16位，规则是最高位（符号位）是什么，就在前面补什么。正的补0，负的补1。1111 1011（-5）扩展成16位是1111 1111 1111 1011，数值还是-5。这个操作保持了数值不变，靠的就是补码本身的数学结构。无符号数做扩展时统统补0，那叫“零扩展”，两者千万别混。

4. 整数运算与溢出：那些悄悄改变结果的边界

接下来聊一个实战中特别容易栽跟头的地方：溢出。

先说无符号整数的边界。一个8位无符号数，最大值是255，如果给它加1，结果不是256，而是回绕到0。为什么？因为8位只能放下256种组合，一旦超过模256，多的部分就被丢弃了。数学上就是256 mod 256 = 0。这就是“整数回绕”（integer wraparound）。

有符号整数就不光是回绕这么简单了，它还存在“正溢出”和“负溢出”。一个8位有符号整数，最大正数是127，127加1会变成-128。这个结果在数学上完全离谱，但在补码运算里就是会发生。因为127的补码是0111 1111，加1后变成1000 0000，最高位变成1，解释为负数，于是得到-128。

我自己有一次在做一个数据累加统计的功能时，就撞上了这个坑。当时的代码简化一下大概是：

c复制int8_t count = 120;
for (int i = 0; i < 10; i++) {
    count++;
}
printf("%d\n", count);

你以为循环10次，count最终是130，但int8_t根本装不下130，结果打印出来是-126。原因就是120加7次到127，第8次溢出变成-128，后面再加2次变成-126。问题不在算法，也不在循环逻辑，就是数据类型容量不够，溢出后“翻车”了。

那怎么判断溢出发生了？有几种手段。

无符号数溢出最好判断：和比任意一个加数都小。如果a + b的结果小于a（同时也小于b），那肯定溢出了。这个方法在C语言里很常用：

c复制unsigned int a = 4294967295u;
unsigned int b = 100u;
unsigned int sum = a + b;
if (sum < a) {
    // overflow happened
}

有符号数的溢出判断要换个思路。补码运算有个规律：两个正数相加得到负数，或者两个负数相加得到正数，一定是溢出了。因为数学上同号相加不应该异号。一正一负相加永远不会溢出，因为结果一定落在范围内的。写成代码就是：

c复制signed int a = 2147483647;
signed int b = 1;
signed int sum = a + b;
if ((a > 0 && b > 0 && sum < 0) || (a < 0 && b < 0 && sum > 0)) {
    // overflow happened
}

这里有个坑中坑：C语言里int溢出本身是未定义行为，编译器假设你不会溢出，在这个前提下做优化，溢出后的表现可能是任何一种。所以我刚才说的“有符号溢出后打印-128”这种结果，在特定编译器和优化级别下是符合预期的，但换个编译器可能就不是这个结果了。你在写代码时，宁可主动用更大范围的数据类型，也不要依赖溢出后的行为。这也是为什么很多安全敏感的代码库会要求所有整数运算都做溢出检查。

5. 类型转换、位扩展与截断：C语言里藏得最深的雷

如果说溢出是“算错了”，那类型转换就是“读错了”。整数在计算机里是死的字节序列，但你对它执行什么操作、把它当成什么类型，决定了你读到的是什么数。类型转换这一节，我觉得是实战中遇到问题最多的部分。

先看“扩展”。把一个占8位的整数存到16位的变量里，如果原数是无符号的，直接在高位补0，这个叫零扩展，简单。如果原数是有符号的，得做符号扩展，高位补符号位。前面说了，这样做才能保持数值不变。

这个逻辑看起来简单，但语言里的隐式转换会悄悄改变类型。比如：

c复制signed char a = -5;
unsigned int b = 2147483648u;
if (a < b) {
    // 你以为a小于b，进入这个分支
}

问题来了：C语言的“整数提升”规则——当有符号数和无符号数混合比较时，有符号数会被隐式转换成无符号数。所以这里的a先被转换成unsigned int，-5在32位下变成4294967291，然后跟2147483648比。结果a反而大于b，if不会进入。这就是网上流传很久的-1 > 0为什么为真的实际案例。

这种坑在写协议栈、文件格式解析、嵌入式底层代码时尤其致命。因为你经常要处理“一个字节先读进来是有符号的，但其他字段是无符号的”这种混合场景。我的建议是：不要在表达式中混用有符号和无符号整数，非要混用，就显式做一次转换，把意图写清楚。

再看“截断”。把一个16位整数强制转换成8位，相当于只保留低8位，高8位直接丢掉。这个方法有时候是有意的——比如你要取一个数的低字节，就直接(uint8_t)(value & 0xFF)；但有时候是无意的——你定义了一个int，然后在某处赋值给一个char变量，编译器只告警不报错，数值就悄悄变了。举个例子：65535在16位下是1111 1111 1111 1111，如果截断成8位，就剩1111 1111，解释为无符号数是255，解释为有符号数是-1。同一个截断结果，解释方式不同，读出来的数差得十万八千里。

还有一个很多人忽略的点：右移运算对符号位的处理。对无符号数右移，高位补0，这没问题。但对有符号负数右移，C标准规定的是“算术右移”，也就是高位补符号位。-16在8位补码里是1111 0000，右移1位变成1111 1000，结果还是-8，而不是0111 1000（正120）。这个行为在理解位操作时很容易踩雷，尤其是你在做协议解析、位域提取的时候。

我做协议解析时有个习惯：凡是涉及移位、取位的操作，一律先把变量显式转换成unsigned类型再操作。无符号数的移位行为在所有编译器下都是一致的、可预期的，有符号数则存在理论上的不可移植性。把问题扼杀在源头上，比事后排查舒服得多。

6. 从二进制到编程实践：几个建议和教训

前面说了原码、反码、补码的理论，又讲了溢出和类型转换的坑。最后把这些落到编程实践上，我结合自己踩过的坑，列几个可以立刻用上的建议。

建议一：选择整数类型时，先想清楚取值范围。 在做底层开发时，很多人习惯“用int就行”，但int的字长在不同平台上是不同的。跨平台代码里，明确使用int8_t、uint16_t、int32_t这种固定宽度类型，比用int、long这种“自然宽度”类型安全得多。尤其是在写协议编解码、文件格式、序列化代码时，字段宽度必须固定，否则在不同的架构上解析结果就不一样。

建议二：警惕隐式的类型转换。 比较运算、算术运算里，一旦有符号数和无符号数混在一起，就存在隐式转换的风险。C语言有编译告警选项可以打开，比如-Wsign-compare和-Wconversion，这些告警不是摆设，每次看到都值得认真处理，而不是直接忽略。

建议三：能避免溢出就避免。 数学意义上的加法在计算机里不一定是加法，满了就会回绕。在涉及数组下标、循环计数、内存分配大小计算的场景，务必确认数值不会超过类型上限。批量处理数据时，如果数量可能很大，用size_t比用int更合适，因为size_t本来就是为了表示对象大小设计的，无符号且宽度足够。

建议四：位操作只用于无符号类型。 只要你是在做移位、取位、掩码这种操作，把操作数显式转为无符号类型。有符号数的右移在标准里是“实现定义”的行为，虽然绝大多数编译器都做算术右移，但写成依赖特定实现的行为，本质上还是在赌运气。

建议五：理解数据手册和协议文档里的字节序。 整数在内存里的字节排列还分大端和小端。同一个0x12345678，在小端机器上低地址是78 56 34 12，大端机器上是12 34 56 78。这个虽然不是整数表示的核心，但一旦涉及跨机器数据传输，整数表示加上字节序问题，就是双重灾难。不少人在做协议对接时收到的数据是反的，根因就在字节序。

最后分享一个我记了很多年的心得：调试整数相关的问题，不要凭直觉猜，把数据用十六进制打出来看。我后来排查那些负数、溢出、字节序的bug，几乎都是靠打印十六进制原始字节定位的。十进制的打印结果会掩盖内存里的真实形态，而十六进制能直接反映位模式。很多看着不可思议的问题，比如“数怎么变成-1了”“为什么加着加着变成负数了”，只要看一眼内存里的十六进制，立刻就能明白是什么环节出了问题。整数的表示虽然是个基础概念，但基础的东西一旦理解透彻，排查问题就是降维打击。