读接口文档看到字段标注 int32，写 C# 时 int 就是它，Java 的 int、Go 的 int32、Rust 的 i32 也都是它。int32 就是 32 位有符号整数，几乎每种语言里都有对应类型。
范围是多少，怎么来的
32 位里最高位做符号，剩 31 位存数值，上限是 2 的 31 次方减 1，等于 2147483647，下限 -2147483648，也就是正负 21 亿上下，占 4 个字节。无符号版 uint32 不留符号位，最大 4294967295，接近 43 亿。顺带纠正一个误会：SQL 里写的 int(11)，那个 11 只是显示宽度，跟存储范围没关系。记两个数就够用：上限 2147483647，下限 -2147483648，各语言同款类型都一样。
几个经典溢出场景
- 2038 年问题：Unix 时间戳按 int32 秒数存，到 2038 年 1 月会超上限，老系统得提前换 64 位
- 游戏数值：伤害、金币超过 21 亿变负数，老玩家说的数值溢出就是它
- 循环变量回绕：加到上限再加一，直接跳成最小值，个别死循环就是这么来的
- 金额计算：单位用分的话，2147 万元就到顶了，做收银、财务系统要心里有数
和前端的坑
JS 的 Number 是浮点数，安全整数到 2 的 53 次方，看着比 int32 大得多。但后端字段标了 int32，前端传个超范围的数，后端照样截断或者报错，接口联调时这种对不上的问题不少见。
什么时候用它
计数器、状态码、枚举值、数据量可控的表主键，int32 够用还省一半内存。用户 ID、订单号、毫秒级时间戳直接上 int64，21 亿看着多，产品一旦起量，ID 逼近上限那天真不好迁。数据库建表时同理，大表主键别顺手建成 int，到时候改类型也是一场折腾。
判断标准一句话：业务峰值乘十倍安全系数后不超过 21 亿就用 int32，拿不准就 int64，多 4 个字节买个踏实。