PHP 解析 JSON 长整数怎么保留完整数字

接口返回的订单号、用户号或雪花 ID 明明是一串完整数字，json_decode() 之后却出现了科学计数法，或者尾部几位对不上。这个问题通常不是打印格式造成的，而是 JSON 数字在解码时被放进了 PHP 的浮点数表示。需要保留原始数字字符时，在第四个参数加入 JSON_BIGINT_AS_STRING，并把这个字段当作字符串一路传递。

长整数为什么会被解析成浮点数

JSON 本身只区分数字和字符串，不替 PHP 决定业务编号的类型。PHP 的 json_decode() 会根据数值大小选择合适的 PHP 类型；当数字不能安全落入本机整数表示时，结果可能成为浮点数。浮点数适合近似计算，却不适合要求每一位都一致的 ID。

下面的例子故意使用 20 位编号。第一种写法让解码器自行选择类型，第二种明确要求大整数保留为字符串：

order_id);
var_dump($safe->order_id);

关键不在 var_dump() 怎么显示，而在 get_debug_type($safe->order_id) 得到的是 string。一旦先变成浮点数，再用格式化函数补零，丢掉的有效位已经无法恢复。

用 JSON_BIGINT_AS_STRING 接住原始数字

json_decode() 的第四个参数是 flags 位掩码，可以把多个常量用按位或组合。实际接口代码通常还应该打开 JSON_THROW_ON_ERROR，这样 JSON 语法错误会抛出 JsonException，调用方不必把所有异常都猜成返回值为空。

如果上游已经把 ID 写成 "12345678901234567890"，它本来就是字符串，JSON_BIGINT_AS_STRING 不会改变它。这个标志主要保护未加引号的 JSON 数字。第二个参数传 true 只决定对象是否转成关联数组，与大整数是否保留是两件事。

把字符串边界传到业务层

保留完整数字只是第一步。不要写 (float)$data['order_id']，也不要为了“统一类型”使用 intval()；这两种转换都会让超长 ID 失去原始语义。比较时使用字符串比较，数据库字段则按项目的 ID 方案选择字符列或足够宽的整数列，写入前后都不要经过 JavaScript 的普通 Number。

如果接口协议可以协商，直接让上游把标识符作为带引号字符串通常更清晰；如果暂时不能改协议，PHP 端统一使用上述 flag，并在边界处检查 ctype_digit()、长度和允许的前导零规则。需要数学运算的值不要伪装成 ID，应采用明确的定点或高精度数值方案。

常见问题

JSON_BIGINT_AS_STRING 会把所有数字都变成字符串吗？

不会。它针对不能安全按整数保存的大整数；普通整数和浮点数仍按对应 PHP 类型解码。

为什么 json_decode() 返回 null？

输入可能就是合法的 JSON null，也可能是语法错误或深度超限。开启 JSON_THROW_ON_ERROR 后用异常分支处理失败，判断结果更明确。

第二个参数写 true 会不会解决精度问题？

不会。true 只把 JSON 对象映射为数组；是否保留长整数要看第四个参数里的 JSON_BIGINT_AS_STRING。

因此，订单号、用户号这类“看起来是数字、实际是标识符”的字段，应在 JSON 解码入口就固定为字符串。这样后面的校验、日志、接口转发和持久化才不会出现同一编号多种写法。