结论先行：Python 整数不会溢出，靠的是「把数字拆成若干 30 位的小节，用对象数组存」——代价是每个整数至少有 28 字节固定开销，且运算复杂度随位数增长：加法近似线性，乘法是超线性的。本文实测 30 万位整数的乘法要 23 毫秒，是 30 位整数的 29 万倍；而同样 30 万位的十进制字符串转换，默认直接被 Python 拒绝——因为 CPython 给字符串转换设了 4300 位的护栏。这篇用 9 组实验把「无限精度」的账单算清楚。
1. 先看内存账单：28 字节起步，每 30 位加 4 字节
C 语言的 int 是定宽的，INT_MAX + 1 直接回绕变成负数。Python 没有这个问题，但它把成本藏在了对象里。实测：
| 整数值 | 位数 | sys.getsizeof |
|---|---|---|
0 |
1 | 28 字节 |
2**30 - 1 |
30 | 28 字节 |
2**30 |
31 | 32 字节 |
2**60 |
61 | 36 字节 |
2**90 |
90 | 40 字节 |
规律非常整齐：固定开销 28 字节，之后每多一个 30 位的「digit」多 4 字节。 注意 0 也要占 28 字节——Python 里没有「小整数更省」这回事，a = 1 和 a = 2**1000 的差别只是后面挂了几节车厢。
2. 为什么是 30 位，不是 32 位
这是最容易被问到的问题。CPython 的 digit 类型是 C 的 uint32_t，32 位宽，但每个 digit 只存 30 位有效值：
>>> hex(2**30 - 1)
'0x3fffffff' # 单个 digit 的最大值
>>> hex(2**30)
'0x40000000' # 立即进位到第 2 个 digit
留 2 位是给进位和中间计算留的余量。乘法中间结果最大能到 60 位，如果 digit 用满 32 位，两个 digit 相乘就需要 64 位临时变量，在老平台和某些编译路径上反而更慢。30 位是精度、速度与可移植性三角平衡的结果，三十年来没变过。
3. 小整数缓存：-5 到 256 的特殊公民
既然每个整数都是 28 字节的对象，for i in range(1000) 难道要创建一千个对象吗？CPython 的解释是：启动时预先建好 -5 到 256 的整数对象，用时只取不建。用运行期构造绕开编译器的常量折叠，边界看得更清楚：
>>> int('256') is int('256')
True # 命中缓存，两次拿到同一个对象
>>> int('257') is int('257')
False # 超出缓存范围，每次新建
这也解释了一个经典面试题：a = 257; b = 257; a is b 在某些环境下是 True——那不是缓存，是编译器把同一代码块里的相同字面量折叠成了同一个对象。判断整数是否相同，请永远用 ==。
4. 运算代价：加法近似线性，乘法超线性
整数拆成 digit 数组后，运算就是对数组的逐节操作。实测不同位数的加法和乘法耗时：
| 位数 | digit 数 | 加法 | 乘法 |
|---|---|---|---|
| 30 | 1 | 0.0001 ms | 0.0001 ms |
| 300 | 10 | 0.0001 ms | 0.0002 ms |
| 3 000 | 100 | 0.0002 ms | 0.011 ms |
| 30 000 | 1 000 | 0.0013 ms | 0.54 ms |
| 300 000 | 10 000 | 0.016 ms | 23.2 ms |
加法是线性复杂度：位数扩大 1 万倍，耗时扩大约 187 倍，基本跟着 digit 数走。乘法是超线性的：位数扩大 1 万倍，耗时扩大约 29 万倍——学校竖式乘法是 O(n²)，CPython 在超过阈值后切换到 Karatsuba 分治乘法才把它压下来，但压不掉「位数翻倍、耗时翻几倍」的本质。这就是为什么「Python 大整数做加密运算慢」的说法有依据：RSA 的模幂就是一连串大数乘法堆出来的。
5. 一个反直觉的坑：str(大整数) 默认会被拒绝
Python 整数没有上限，但把大整数转成十进制字符串有上限：
>>> import math, sys
>>> sys.get_int_max_str_digits()
4300
>>> str(math.factorial(10000))
ValueError: Exceeds the limit (4300 digits) for integer string conversion
math.factorial(10000) 有 35660 位十进制数字，超过 4300 的护栏直接抛异常。这是 CPython 针对 CVE-2020-10735 的修复：攻击者可以提交一个千万位的整数让服务器转字符串，O(n²) 的转换算法会拖死进程。解法是 sys.set_int_max_str_digits(200000) 显式放宽。
这也解释了日常调试的困惑：print(2**5000) 好得很，print(math.factorial(10000)) 突然崩了——不是数字太大存不下，是十进制转换太贵被主动熔断。
6. 序列化选二进制，能快三个数量级
同一个 3 万位整数，实测不同出口的耗时：
| 转换方式 | 输出长度 | 耗时 |
|---|---|---|
str(x) |
9031 字符 | 1.83 ms |
hex(x) |
7502 字符 | 0.013 ms |
x.to_bytes(3750,'big') |
3750 字节 | 0.006 ms |
十进制转换比二进制转换慢约 300 倍——因为 10 不是 2 的幂，每输出一位都要做一次除法迭代；而 to_bytes 只是按 30 位一节重新拼装，近乎零成本。需要把大数写进日志、传上网络、存数据库时，走 to_bytes/from_bytes 或 hex，别用 str。
7. 那什么时候不该用 Python 整数
数值计算里用 list 装一百万个整数，实测内存约 26 MB 起（每个元素一个 28 字节对象加 8 字节指针），而 array('q') 定宽 C 整数只要 7 MB。Python 整数的无限精度，对大多数场景是过剩的——图像像素、音频采样、矩阵运算，数据本身有界，就该用定宽容器；只有密码学参数、组合数学的阶乘、大数分解这类「位数自己会长」的场景，才配得上这份灵活性。
一句话收尾：Python 整数的「永不溢出」不是免费的魔法，而是 28 字节起步、4 字节一节的显式账单——加法线性、乘法超线性、十进制转换默认熔断。知道账单在哪，才知道什么时候该为这份自由买单。
