php整型溢出会导致值静默回绕（如php_int_max+1变php_int_min），而非报错；应默认用字符串处理大数，配合json_bigint_as_string、pdo::attr_stringify_fetches及gmp/bcmath扩展应对高精度需求。
PHP整型溢出时值突然变负或归零
PHP的int在32位系统上最大是2147483647，64位系统是9223372036854775807；一旦运算结果超出范围，就会静默回绕（比如PHP_INT_MAX + 1变成PHP_INT_MIN），而不是报错或抛异常。你看到的“计算结果不对”“ID突然变负数”“订单号错乱”，大概率就是这个原因。
关键不是“怎么检测溢出”，而是“别让它发生”——PHP原生int不提供溢出检查机制，硬判if ($a > PHP_INT_MAX)没用，因为溢出早已在赋值/运算时完成。
- 对ID、金额、计数器等可能超限的场景，**默认改用字符串存储和处理**，尤其涉及数据库主键、外部API返回值、分页偏移量
- 避免用
intval()或强制类型转换(int)解析大数字字符串，比如(int)"9223372036854775808"在64位下直接变9223372036854775807 - 读取JSON时加
JSON_BIGINT_AS_STRING选项，防止json_decode()把大整数转成float再截断
用GMP或BCMath处理真正的大整数运算
如果必须做加减乘除模幂等运算（比如加密、哈希、大额精确计算），不能靠字符串拼接，就得选扩展。GMP更快更全，但依赖系统库；BCMath内置、精度可控，但只支持十进制字符串操作。
选哪个？看场景：
– 需要位运算、素数判断、大质因数分解 → 用gmp_add()、gmp_mod()
– 只需高精度加减乘除、保留小数位（如财务计算）→ 用bcadd()、bcmul()，记得设bcscale(2)
立即学习“PHP免费学习笔记（深入）”；
-
gmp_init()接受字符串，但别传float，否则精度已丢；gmp_strval()转回字符串，别用(string)强转 -
bcadd("12345678901234567890", "98765432109876543210", 0)结果是字符串，不是int - 注意
bcdiv()除零会警告，gmp_div_qr()除零直接致命错误
数据库字段和API交互时的隐性溢出
MySQL的BIGINT UNSIGNED能存到18446744073709551615，但PHP的int在Windows 64位上仍是带符号的，读出来就可能被截断或变负。PDO默认把整数列映射为PHP int，哪怕数据库里是bigint。
- PDO连接时加
PDO::ATTR_STRINGIFY_FETCHES => true，让所有数值字段返回字符串 - Laravel用户可在
config/database.php中给MySQL连接加'options' => [PDO::ATTR_STRINGIFY_FETCHES => true] - 对外提供API时，用
json_encode($data, JSON_NUMERIC_CHECK)会把字符串数字又转回number，导致前端JS再次溢出（JS安全整数上限仅2^53-1），应统一用字符串传数字字段
为什么不要自己写“溢出检测函数”
有人想写个safe_add($a, $b)来判断是否溢出，逻辑类似if (($a > 0 && $b > 0 && $a > PHP_INT_MAX - $b) || ...)。这看似合理，但实际不可靠：
- PHP 8.1+ 引入了
intdiv()等函数，但没补溢出检测；核心开发明确表示“这不是语言该管的事” - 浮点中间计算（如
PHP_INT_MAX - $b）可能因精度丢失导致误判 - 多线程/协程环境下，
$a和$b可能在判断前后被修改，检测失去意义 - 真有这种需求，说明业务模型已超出PHP原生整型适用范围——该换方案，不该补洞
最常被忽略的是：溢出问题往往不在计算过程，而在数据落地那一刻。比如从RedisINCR拿到一个超大整数，直接赋给int变量，还没开始算就已经错了。
