带新人的时候我经常发现一个奇怪的现象：很多能写复杂业务逻辑的工程师，面对"整数在计算机里是怎么表示"这个问题，会突然变得含糊其辞。直到有一次，一个实习生跑完统计任务，拿着-1949672955这个计数值来找我，说自己怀疑数据源坏了。我让他打印一下循环的计数器，他这才意识到问题出在哪——一个int计数器根本装不下几亿次累加的结果。这件事让我特别有感触：我们每天都在写整数、用整数，但真正理解整数表示原理的人，远比想象中少。
这篇内容想把这件事讲透。它不是什么高深的前沿技术，恰恰相反，它藏在每一门编程语言的第一章、每一本《计算机组成原理》的教材里，但翻开互联网上的讨论，你会发现大量关于"32位有符号整数""C++次方怎么表示""16位整数转换16位浮点数""整数奇偶排序"的困惑都源于同一个根子：没有把整数的底层表示真正理解到位。如果你是学生，这篇文章能帮你把那块最难啃的硬骨头啃下来；如果你是写业务代码的工程师，看完之后，你至少能明白那些线上诡异 bug 的来龙去脉。
1. 整数表示：所有编程语言的第一块基石
1.1 一个让全组人沉默的统计结果
当时那个实习生的任务很简单：读一个大文件，统计某个事件出现的次数。文件大概有 10 个 G，他写了个 Java 程序，循环遍历每行，命中就count++。跑了好几个小时，最后打印出来的结果是个负数。
他问我："是不是文件里有损坏的字节？"
我让他看代码。代码逻辑完全正确，文件本身也没有问题。真正的问题是：int类型的最大值是2147483647，也就是大约 21 亿。一旦计数超过这个值，整数的表示方式就会从正数区间回绕到负数区间，计数器变成负数。
这个场景我后来在面试里讲过很多次。很多人第一反应是"这题太简单了，int 溢出而已"，但你再追问一句："为什么恰好是 21 亿？为什么回绕之后不是报错而是变成负数？负数的最小值为什么比正数的最大值大 1？" 能完整答上来的人就很少了。
大多数人上课时记住了"int 是 32 位、范围 -2147483648 到 2147483647"，但记这些数字没有任何意义，因为下次遇到long、遇到数据库里的BIGINT、遇到 Python 里看起来可以无限加的整数，数字又全变了。真正应该记住的是这张表背后的推导逻辑。
1.2 搜索记录暴露了真实的困惑
我写这篇文章之前，专门翻了翻和这个主题相关的高频搜索词。很有意思：整数排序、bash脚本定义整数变量、32位有符号整数、计算机组成原理、16位整数转换16位浮点数、C++次方怎么表示、MySQL可以存储整数数值的是、整数奇偶排序……这些词看似分散，其实都指向同一个缺口。
比如C++次方怎么表示，表面上是忘了一个函数名，实际上是没理解整数的位运算和浮点数的幂运算在底层是两套完全不同的机制。16位整数转换16位浮点数，本质上是没搞清整数和浮点数在内存中的位模式截然不同。bash脚本定义整数变量，是因为发现 shell 里所有变量默认都是字符串，想强行走整数运算却踩了类型转换的坑。这些表面上的 API 问题，底层全是表示问题。
所以你去看再多的函数手册，不如把整数的底子打牢。接下来我用最通俗的方式，把这套底子一层层拆开。
2. 从位权到补码：整数表示的底层逻辑
2.1 为什么计算机偏偏选中了二进制
人类发明了十进制，但计算机内部用的是二进制。为什么？因为实现"只有两种状态"的物理器件比实现"有十种状态"的器件容易太多，也可靠太多。
你想想，一个开关，要么打开、要么关闭；一个晶体管，要么导通、要么截止；一块磁盘表面，要么有磁性、要么没有磁性。所有物理媒介天然都是二态的。如果要做一个能表示 0 到 9 十种状态的器件，你得精确控制十个电压区间，抗干扰能力会差到没法用。
所以计算机用二进制不是爱好，是物理现实。一个二进制位称为 1 bit，它是信息的最小载体。8 个 bit 组成 1 个字节（byte），这是大多数处理器的基本寻址单位。整数在计算机里，本质就是一段固定长度的 bit 序列，比如 32 位就是一个由 32 个 0 或 1 组成的串。
给这些 bit 赋予数值，靠的是位权（weight）规则。二进制的每一位都有对应的权值，从右往左依次是 1、2、4、8、16……也就是 2 的幂。比如二进制1101，按位权展开是：
1×2^3 + 1×2^2 + 0×2^1 + 1×2^0 = 8 + 4 + 0 + 1 = 13这套规则和十进制一模一样，十进制从右往左是 1、10、100、1000，二进制不过是把基数换成了 2。到这里，"正整数的二进制表示"已经清楚了。接下来麻烦的是负数。
2.2 原码、反码、补码：三代方案的演进
人类的第一直觉是，用一位来专门表示符号：0 代表正，1 代表负，剩下的位表示绝对值。这就是原码。比如用 8 位表示 +13 是00001101，-13 是10001101。
原码看起来友好，用起来全是问题。首先是 0 有两种表示：00000000和10000000都表示 0，这让判断"是否为零"变得复杂。更致命的是，直接拿原码做加法是错乱的：00001101（13）加上10001101（-13），结果是10011010，这显然不是 0。
于是有了反码：正数不变，负数在原码基础上把符号位之外的位全部取反。-13 的反码是11110010。反码解决了正负数相加的部分问题，但 0 还是有正负两种表示。
最终的方案是补码：正数不变，负数在反码基础上再加 1。-13 的补码就是11110011。补码的一大功劳是：0 只有一种表示，00000000；另一个功劳是，加法器可以直接处理减法，CPU 不需要专门设计一套减法电路。你把00001101和11110011相加试试：
00001101 + 11110011 ---------- 100000000结果是 9 位，最高位的 1 被 8 位寄存器丢掉，剩下00000000，刚好是 0。13 加 -13 等于 0，完美。
2.3 补码的本质：模运算下的统一加法
补码为什么要"取反加一"？很多人背了这个规则却完全不知道为什么。我来给你一个真正好理解的角度：模运算。
你想想钟表。钟面只有 12 个小时，过了 12 就回到 1。在这个世界里，9 点加 4 个小时等于 1 点，因为9 + 4 = 13，13 对 12 取余是 1。那么请问，在钟表世界里，怎么表示"减 4 小时"？答案是加 8 小时，因为12 - 4 = 8。减 4 等价于加 8，这就是模运算的等价关系。
n 位二进制的情况一模一样。n 位能表示的状态总数是2^n，所以它的"模"就是2^n。任何运算结果如果超出 n 位，就相当于对2^n取模，超出的高位直接丢弃。于是"减 x"就等价于"加2^n - x"。
2^n - x怎么算？二进制里一个技巧：2^n - x等于(2^n - 1) - x + 1。而(2^n - 1)是 n 位全是 1 的数，减去 x，恰好等于把 x 的每一位取反。所以：
-x 的补码 = 取反 + 1这就是"取反加一"的来源。它不是什么魔法，只是模运算的必然结果。补码的真正价值，是把减法统一成了加法，让 CPU 只造一个加法器就能完成所有整数加减运算，硬件因此极大地简化。
3. 有符号整数的边界：最大值、最小值与溢出回绕
3.1 -2147483648 到 2147483647 是怎么算出来的
既然补码要存储负数，那么符号位还要不要单独留？答案是要，但符号位已经融合在补码规则里了：最高位为 1 的数，一律解释为负数。换句话说，补码体系里的"符号位"只是位模式的一种自然属性，它不再是独立的一位。
拿 8 位来说。能表示的位模式一共2^8 = 256种。其中最高位是 0 的，是00000000到01111111，对应 0 到 127，共 128 个数。最高位是 1 的，是10000000到11111111，它们在补码规则下分别对应 -128 到 -1，也是 128 个数。所以 8 位有符号整数的范围是-128 ~ 127。
推广到 32 位，范围就是-2^31 ~ 2^31-1。正数这边，因为要把 0 也算进去，所以最大值只能是2^31 - 1 = 2147483647；负数这边没有这样的限制，最小值是-2^31 = -2147483648。于是出现了那个著名的"不对称"：负数的最小值比正数的最大值在绝对值上大 1。
不理解这个推导的人，容易把2147483647当成一个需要死记硬背的常数。而掌握了位权的人，随时能从"32 位、补码表示"这几个词还原出全部边界。顺手记一下：64 位有符号整数，也就是long，范围是-9223372036854775808 ~ 9223372036854775807。
3.2 溢出后的回绕：为什么结果是负数而不是报错
回到文章开头的实习生例子。int加法一旦越过2147483647，结果会从-2147483648重新开始。这是补码位模式的必然结果：01111111...再加 1，所有位进位，变成10000000...，解释为负数最小值。
这种回绕行为在 Java 中有一套明确定义，但 C 和 C++ 里，有符号整数溢出属于未定义行为（undefined behavior），编译器可以合理假设你永远不会溢出，然后基于这个假设做各种激进的优化。这就可能带来更隐蔽的问题：代码在 Debug 模式下正常，在开优化后行为大变。
我见过一个真实的线上事故，问题出在二分查找：
int mid = (left + right) / 2;当left和right都接近 21 亿时，left + right直接溢出变成负数，mid变成一个完全错误的索引，程序陷入死循环或者数组越界。类似的问题还出现在循环控制变量、事件计数器、自增主键等所有可能越过 21 亿的场景。经典修复是把参数写成相减的形式：
int mid = left + (right - left) / 2;这样right - left永远不超范围，加法也安全得多。这段代码看起来只是一个小改动，背后的含义却是：你彻底理解了整数溢出的机制，而不是祈祷数据不会触及边界。
3.3 防御溢出的几种实用手段
我从实际项目里总结了几层防溢出措施，按成本从低到高排列：
- 改大类型。Java 里
int换long，C 里改用int64_t，数据库从INT换BIGINT。这是最直接有效的办法，但要注意：Java 的long也有上限，只是那个数字大到绝大多数业务到不了。 - 变化运算写法。像二分查找那样，把加号改成减号加除号，从根上缩小中间量。
- 用语言提供的安全运算。比如 Java 的
Math.addExact、Math.multiplyExact，溢出时直接抛ArithmeticException。Go 语言没有内置溢出检查，得靠 go vet 之类工具辅助。 - 对金额和 ID 这类关键数据，测试用例强制覆盖边界值。比如测试计数器达到
2147483647后再加 1 会怎样，测试订单号到达9.2e18会怎样。多数公司不会测，一旦出问题就是大事故。
提示：不要迷信"我们业务量永远到不了 21 亿"。互联网产品的峰值是突然来临的，而数据一旦存进数据库，类型想改就要经历漫长的迁移。
4. 不同语言对整数的态度，决定了你踩坑的方式
4.1 C/C++ 的 int：祖先留下的宽松规则
C 语言对整数的定义给足了自由度：int至少是 16 位，在绝大多数现代平台上是 32 位，但标准没有写死。long更麻烦，在 Windows 上是 32 位，在 Linux 64 位系统上是 64 位。char到底有没有符号，也是"由实现定义"。
这种宽松性源于 C 语言追求跨平台效率的初衷。对系统级编程来说它是必要的，但对应用层工程师来说，它成了大量坑的源头。你在一台机器上调试好的代码，换个编译器、换个平台，溢出行为可能就不一样。
C++里还有一个和整数表示强相关的经典迷惑：^不是幂运算，而是按位异或。新手写a ^ b想算 a 的 b 次方，结果得到一个完全不是预期的整数，因为在二进制位模式下，异或只是逐位比较 0 和 1。想要幂得调pow，但pow返回double，对大整数有精度损失，所以对整数场景更可靠的做法是手写快速幂：
long long quickPow(long long a, int b) { long long result = 1; while (b) { if (b & 1) result *= a; a *= a; b >>= 1; } return result; }这段代码里用到b & 1判断奇偶、b >>= 1做除 2，全是位运算与整数的直接配合。只有理解了补码和位权，你才能读懂这类写法为什么不依赖浮点，也不会丢精度。
4.2 Java 把行为写死在规范里
Java 选择了和 C 相反的路：int永远 32 位，long永远 64 位，不管你在什么平台上跑。代价是 JVM 承担了跨平台适配的工作，但换来的是程序行为的高度可预期。对绝大多数业务开发来说，这个取舍非常值得。
Java 里还有个细节：char是 16 位无符号整数，byte是 8 位有符号整数。当你把byte转成int时，会发生符号扩展。比如一个byte的0xFF代表 -1，直接赋给int会变成0xFFFFFFFF，也代表 -1。如果你期望得到255，就得用b & 0xFF掩掉符号位。这些都是面试常考点，也是实际编码中容易踩的坑。
另一个常见的 Java 整数问题是hashCode可能是负数。比如自定义对象作为 HashMap 的 key 时，如果hashCode直接取整数属性，负数天然可能出现。HashMap 内部用hash & (table.length - 1)来求桶下标，这种位运算能正确应对负数。但你如果自己写类似hashCode() % bucketCount的代码，取模结果可能是负数，导致数组越界。正确做法是Math.floorMod(hash, bucketCount)或hash & 0x7fffffff % bucketCount这类先归正再取模的方式。这种问题看起来是取模的写法问题，根子还是对补码符号位理解不透。
4.3 Python 的任意精度整数：方便还是负担
Python 3 的整数是任意精度的，随你怎么加都不会溢出。它是把整数拆成多个 30 位的小段（digit），按位拼接存储，段数会随着数值增大而动态增加。所以2**1000在 Python 里直接就能算出来，这在 C 和 Java 里无从谈起。
好处显而易见：写算法题的人再也不用担心大数溢出，不需要手写高精度运算。坏处也很明显：任意精度是靠堆内存换来的，每个大整数对象都有额外开销，加法的复杂度不再恒定，而是和数值的位数成正比。在性能敏感的场景，比如批量流式计算、高频交易、图像处理里，Python 的整数开销会成为明显的瓶颈。
顺便一提，Python 的**也是整数幂运算，它背后是一套复杂度不错的快速幂算法，但如果你需要一个超大的数并频繁取模，还是得用专门的大数库或直接用 C 扩展。
4.4 数据库里的整数：INT 与 BIGINT 的选型
MySQL里，INT占 4 字节，有符号范围约 -21 亿到 21 亿，无符号范围 0 到 42 亿；BIGINT占 8 字节，范围约 -9.22e18 到 9.22e18。开发中我见过最多的表结构问题，就是主键用了INT，然后业务增长到千万甚至亿级后开始焦虑。
我的建议很简单：凡是主键、订单号、流水号这类会只增不减的 ID，直接上BIGINT。虽然它比INT多占 4 字节，但在现代磁盘和内存面前这点代价可以忽略，换来的是未来十年的安心。状态码、枚举值、年龄、数量这类有明确上限的字段才适合INT甚至TINYINT。
还有一个容易错的点：不要把手机号、身份证号这类看起来像数字的值存成整数。它们不参与数值运算，而且位数可能超过 32 位，存成INT必然溢出或需要用BIGINT和字符串转换，自找麻烦。正确做法是存成字符串。
5. 硬件视角：整数运算在电路里怎么跑
5.1 加法器：一切整数运算的地基
CPU 里负责整数运算的核心模块叫 ALU（算术逻辑单元）。它的心脏是加法器。加法器怎么工作？先看一位加法，两个数 A 和 B 相加，得到本位和 S 以及向高位的进位 C。
- 半加器：没有低位进位输入，只能处理一位加法。
- 全加器：多了一个进位输入端
Cin，可以把两个一位数以及低位的进位一起相加。
把 32 个全加器串联起来，就构成了 32 位加法器：每一位的结果依赖低一位传来的进位。有了补码，减法就变成了"被减数加上减数的补码"，也就是加一个负数。于是同一个加法器既能做加法又能做减法，这是补码在硬件层面的价值。
5.2 进位链：为什么加法有延迟
串行进位也叫行波进位，是最直观也最慢的加法器结构。问题是进位的传播路径：最低位产生的进位要逐步传递到最高位，最坏情况下，进位信号要穿过整整 32 级加法器，每一级都有门延迟，加起来就是不可忽视的时间开销。
这就引出了"组间串行进位"这类优化思路。把 32 位分成若干个小组，每组内部用超前进位逻辑快速算出组内的和与组间进位，组与组之间再串行传递进位。组内并行，组间串行，速度远快于纯串行，这就是计算机组成原理教科书里那类题目的意义。你看到热搜词里的"组间串行进位"，就是在问这个结构。
理解进位链，对写代码的启发是：在高性能算法和并发编程里，那些看起来简单的加法和乘法，在硬件层面并不便宜。尤其是在循环体里，编译器优化会尝试转换运算形式，但你不应该把"加法很快"当成永久真理。
5.3 移位运算与乘除法的关系
左移一位，相当于乘以 2；右移一位，相当于除以 2 再向下取整。这是二进制位权的直接推论。
- 逻辑左移
x << 1：所有位向左移，最低位补 0。 - 逻辑右移
x >> 1：所有位向右移，最高位补 0。 - 算术右移：最高位保持原来的符号位不变，所以负数右移仍然保持负数性质。
C 和 C++ 对"有符号整数的右移"定义为算术右移还是逻辑右移，标准并没有完全写死，但绝大多数编译器的行为都是算术右移。Java 则用>>表示算术右移、>>>表示逻辑右移，定义清晰。
编译器经常把乘以常量改成移位加加法。比如x * 10可能被优化成(x << 3) + (x << 1)，因为 CPU 移位单元比乘法器快得多。你在写代码时如果能主动意识到这一点，写出来的算法效率会明显更高。
6. 高频"整数题"背后的考察点：从数 1 到奇偶排序
6.1 统计 1 到 n 中数字 1 的个数
题目是：给定一个十进制正整数 n，写下从 1 到 n 的所有整数，然后统计其中出现的数字 "1" 的个数。很多人第一反应是循环：
int countOnes(int n) { int count = 0; for (int i = 1; i <= n; i++) { int x = i; while (x) { if (x % 10 == 1) count++; x /= 10; } } return count; }这个写法在 n 较小时没问题，但 n 到亿级别就会非常慢。更好的做法是按位统计：分别计算个位、十位、百位……上出现 1 的次数，加起来。核心思想是把每个数位拆开，利用整数表示中的位权规律。
这类题表面上是考编程，实际上是考你对"十进制位数与位权关系"的理解。你把一个整数拆成高低位时，本质上就是在操作它的位模式，只不过基数是 10 而已。理解了整数在计算机里的二进制表示后，你会发现这类"拆位统计"题是相通的：二进制里数 1 的个数也可以逐位统计或查表加速。
6.2 整数奇偶排序：奇偶本质是二进制最低位
经典题目1181: 整数奇偶排序：给定 10 个整数，要求奇数在前、偶数在后，并且奇数和偶数的内部顺序要保持输入时的相对顺序。
初学者最容易踩的坑是用不稳定的排序（比如std::sort）直接排序，结果破坏了相对顺序。正确解法是开两个数组，扫描一遍原数组，奇数放前面数组，偶数放后面数组，最后合并。判断奇偶的标准是什么？x % 2可以，但更底层的判断是x & 1。一个整数的二进制最低位是 1 就是奇数，是 0 就是偶数。这个视角在性能敏感场景很有用，因为位运算比取模快。
这类题目的价值在于：它让你意识到"奇偶"不是数学上的抽象概念，而是整数的二进制表示中最直观的一个属性。当你习惯了从二进制角度看整数，很多题目会变成一眼题。
6.3 幂运算与进制转换的表示陷阱
C++次方怎么表示这个搜索词折射出不止一个困惑。在 C++ 里，^是按位异或，不是幂。如果你真想算整数幂，应该好好想想：底数和指数都是整数，中间会不会溢出？浮点pow的返回值是否能精确表示结果？
另一个类似主题是进制转换。十进制转二进制、十六进制转二进制，本质都是位权展开的逆操作。16位整数转换16位浮点数这个热搜词很有代表性：很多初学者以为把整数的小数点"挪一挪"就变成浮点数了，其实完全没有理解浮点数使用的是另一套表示法——符号位 + 指数位 + 尾数位。整数 16 在内存里是0000000000010000，而浮点数 16.0 的位模式完全是另一回事。从这个角度看，理解整数表示是理解浮点表示的必经之路。
7. 我在生产环境踩过的整数坑
7.1 时间戳、订单号、金额的 64 位时刻
Unix 时间戳是一个以秒为单位的整数，32 位有符号整数的上限到 2038 年就会溢出，这是 IT 行业人尽皆知的话题。但现实中更多项目的问题是：根本没有意识到某些字段会触及 32 位边界。
我见过一个订单系统，早期用INT存订单号，单量冲到日均百万后没多久就告警了。虽然当时还在 21 亿以内，但增长率一算，明年就爆。这种问题如果等爆了再改，只能停机做表结构迁移，压力极大。所以设计表的时候就要有"预判边界"的思维：凡是主键、订单号、会话 ID、累计计数，一律BIGINT。
金额问题更隐蔽——很多系统拿浮点存金额，然后算着算着出现 0.1 + 0.2 不等于 0.3 的诡异问题。金额应该用整数存"分"（最小货币单位），或者用定点数类型，而不是浮点。这又一次验证了表示的重要性：选错表示法，代价会在意想不到的地方冒出来。
7.2 hashCode 的符号问题与分区计算
Java 的hashCode()返回int，可以是负数。如果拿它直接做取模路由，比如hashCode() % 10，负数结果会导致请求路由到负数下标，典型的数组越界或分区错乱。
正确姿势是先对哈希值做"无符号化"处理，再取模：
int bucket = (hash & 0x7fffffff) % bucketCount; // 或者 int bucket = Math.floorMod(hash, bucketCount);这里用& 0x7fffffff把符号位强制改成 0，让整个整数变成一个非负数，但会丢失负数的范围信息。如果要保留全部 32 位的分布，更好的做法是把int转成long再取模：
int bucket = (int) (Integer.toUnsignedLong(hash) % bucketCount);这类问题的根子，还是对"最高位是符号位、负数在补码下位模式长什么样"不够敏感。一旦你真正消化了补码，这种 bug 在你眼里会是透明的。
7.3 隐式类型转换中的符号扩展陷阱
C 语言里有个经典坑：
char c = 0xFF; // 如果 char 是有符号的，这里等于 -1 if (c == 255) { // 永远进不来 } if (c > 0) { // 也永远进不来 }原因很简单：有符号char的0xFF在补码表示下是 -1。当它参与比较时，会先发生整型提升，变成int的0xFFFFFFFF，仍然是 -1。要得到 255，必须写成(unsigned char)c或者c & 0xFF。
无符号与有符号混合比较是另一个雷区：
int a = -1; unsigned int b = 1; if (a < b) { // 你会以为进得来，其实进不来 }为什么？因为 C 的隐式转换规则会把a从有符号转成无符号，-1 的无符号表示是4294967295，跟 1 比较自然大于。看着是"小于 1"，实际变成了"最大的无符号数大于 1"。
这种坑对写过几年 C/C++ 的程序员来说司空见惯，但对新手而言足够劝退。理解了补码和符号扩展，你就能解释每一个位的变化，而不是死记"不要拿有符号和无符号比较"这种结论。
我自己的习惯是，遇到整数参与的运算，先问三个问题：这个值的可能范围是什么？运算中间量会不会越过当前类型的边界？有没有隐式转换在悄悄改变语义？把这几个问题过一遍，绝大多数整数相关的坑都能在写代码阶段提前堵住。如果你现在还觉得"整数嘛，能加能减就不就完了"，希望这篇文章之后，你能换个视角看这个老朋友。
