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 变量，还没开始算就已经错了。
