写代码时遇到过这种事没？明明输入的是 100000，加几次之后突然变成 -2147483648，或者直接崩了报错 OverflowException。不是你算错了，是整数类型在偷偷设限。
整数不是无限大，它有“户口本”
计算机里存整数，靠的是固定位数的二进制。比如一个 int 在 Java 或 C# 里默认是 32 位，能表示的范围就是 -2147483648 到 2147483647；C 语言里的 short 通常只有 16 位，上限才刚过 3 万（32767）。超出这个范围，就像身份证号填了 20 位——系统不认，直接溢出或截断。
不同语言，限制不一样
Python 看似“无所谓”，999**999 也能算，那是因为它用的是动态大整数（bignum），自动扩容。但代价是速度慢、内存多。而 Go 默认的 int 在 64 位系统上是 64 位，但在 32 位环境里可能缩成 32 位——同一段代码，换个机器就翻车。
JavaScript 更特别：它压根没有整数类型，所有数字都是 Number（双精度浮点），能精确表示的整数上限是 2^53 - 1（约 9007199254740991）。超过这个数，9007199254740992 === 9007199254740993 居然返回 true——这不是 bug，是浮点精度的硬伤。
真实踩坑现场
某电商后台统计订单 ID 总和，ID 是 10 位数字（比如 1234567890），用 int 累加 3000 单，总和轻松突破 21 亿，直接溢出变负数，导致库存扣减逻辑反转。查日志发现扣了 -12345 件货……
还有个老项目用 unsigned char（0~255）存用户等级，运营一搞“满 256 送神装”，等级从 255 加 1 变成 0，VIP 用户秒回新手村。
怎么防？看场景选类型
数据库字段也得同步考虑：TINYINT 最大 255，INT 默认 4 字节，BIGINT 才撑得住百亿级 ID。前后端传参时，Java 后端用 Long，前端 JavaScript 却用 Number 接，超 2^53 的 ID 就会丢精度——这时候得传字符串。
简单原则：预估最大值 × 1.5，再往上靠档。比如预计最多 1000 万条记录，别用 INT 冒险，直接上 BIGINT；计时毫秒值（现在时间戳是 17 位数），必须用 long 或 bigint，int 早过时了。
小检查清单
- 变量声明前，心里默念：“它最大可能到多少？”
- 循环累加、乘法、时间戳计算，优先选更大范围类型
- 跨语言/跨系统传整数，确认双方对“整数”的理解是否一致
- 测试别只跑正常值，加一条
MAX_VALUE + 1看会不会炸
整数类型限制不是玄学，是硬件和设计留下的实在边界。看清它，比等它出事再 debug 省十倍力气。