Python 3 的 int 没有数学上限，仅受内存限制；其底层采用 PyLongObject 结构体，以动态数组 ob_digit[] 分段存储大数，按需分配内存，实现任意精度。
Python 3 的 int 是怎么做到“无限大”的？
因为底层用了变长存储结构：每个 int 对象实际是一个 PyLongObject 结构体，包含一个动态数组 ob_digit[]。数值越大，数组越长，内存按需分配。这和 C 里固定 4 字节或 8 字节的 int 完全不同——它不是“扩位”，而是“分段拼接”。
Python 2 的 int 和 long 分开是为了解决什么问题？
当时为了兼顾性能和兼容性：int 用机器原生整数（如 32 位），快但会溢出；long 用任意精度实现，安全但慢。开发者必须手动判断大小、显式转成 long，比如 1L 或 long(10**10)。
- 写
2**31 - 1 + 1在 Python 2 里可能抛OverflowError -
type(100)是<class 'int'>，但type(10**100)是<class 'long'> - 函数返回类型不一致，容易引发隐式类型错误
为什么 Python 3 直接取消了 long 类型？
统一类型能消除边界模糊带来的坑，比如：
- 不再需要写
12345678901234567890L这种后缀 -
range()返回的是range对象，但遍历时生成的每个元素都是统一的int - 所有算术运算（
+、//、pow()）都自动适配大小，无需用户干预 -
sys.maxint被移除，sys.maxsize仅反映容器索引上限，和整数本身无关
那“没限制”是不是真没代价？
不是。代价藏在三处：
立即学习“Python免费学习笔记（深入）”；
- 内存：一个 100 万位的整数，
sys.getsizeof()可能返回几 MB，不是几个字节 - 速度：
10**1000000.bit_length()比1000.bit_length()慢两个数量级以上 - 序列化：JSON 不支持超大整数，
json.dumps(10**1000)会报OverflowError，得先转字符串
真正容易被忽略的，是跨系统交互时的隐性断裂——比如你把一个 Python 生成的 500 位整数传给 JavaScript，对方 parseInt 会直接丢精度，连 warning 都没有。
