PHP json_decode 怎样避免大整数被转换为浮点数

接口返回的订单号、雪花 ID 或外部系统编号如果超过 PHP 默认整数表示范围，直接调用 json_decode() 可能得到浮点数。真正稳妥的处理不是在 json_encode() 前临时补转换，而是在解码入口使用 JSON_BIGINT_AS_STRING，让这类字段从进入业务代码开始就保持字符串。

官方参考：https://www.php.net/manual/en/function.json-decode.php

这篇只讨论“大整数怎样避免被转换为浮点数”。普通小整数仍按 PHP 的常规类型解码；如果还需要区分语法错误，再叠加 JSON_THROW_ON_ERROR。

大整数变成科学计数法，问题在解码入口

先看一个常见的接口片段：

order_id);

PHP 手册给出的边界是：大整数在默认解码下可能得到浮点数，示例中的 12345678901234567890 会显示为科学计数法；一旦发生二进制浮点舍入，后面再转回字符串也不能恢复原始数字。

把“数值”与“标识”分开处理

大整数不一定是“需要计算的数”。金额、数量和计数通常需要数值语义；订单号、用户号、设备序列号则更像不可拆分的文本标识。后者优先保留字符串，才能避免前导位、末位或比较结果受到浮点精度影响。

因此，策略可以按字段语义划分：

这不是把所有 JSON 数字强行变成字符串，而是先确认字段是否具有“标识”语义，再决定解码策略。

JSON_BIGINT_AS_STRING 的可靠写法

在解码时把标志位放到第四个参数，并建议同时启用 JSON_THROW_ON_ERROR：

getMessage());
    throw $e;
}

这里的关键点有三个：第四参数才是 flags；位运算符 | 可以组合多个标志；JSON_BIGINT_AS_STRING 只影响超出正常整数表示边界的大整数，不会把 3 这样的普通数字全部改成字符串。

为什么在 json_encode 前补转换已经晚了

如果默认解码已经把长整数变成 float，业务层再写 (string)$value 得到的只是浮点值的文本表示，不是输入 JSON 中的原始数字。这个补救动作看起来能让类型变成字符串，却无法回收已经丢失的精度。

还要注意，字符串化后不能再直接参与算术。若业务确实要计算超大整数，应交给适合的高精度方案；如果它只是外部 ID，则应该在接口校验层明确要求字符串，并在序列化时保持一致。

上线前按四个问题检查

1. 这个字段是要计算的数，还是只用于识别和传递的标识？
2. 所有入口是否都在 json_decode() 处统一设置了大整数策略？
3. 是否组合了 JSON_THROW_ON_ERROR，避免把解析失败误当成空结果？
4. 字段校验是否明确区分字符串 ID、普通整数和金额类型？

结论很简单：如果 JSON 大整数代表订单号、雪花 ID 或序列号，就在解码时使用 JSON_BIGINT_AS_STRING；不要等到浮点值已经进入业务层后再做字符串转换。这样保留的是原始标识的文本语义，后续校验、日志和再次编码也更稳定。

相关问题

• JSON_BIGINT_AS_STRING 会把所有整数都变成字符串吗？不会，它主要处理超出正常整数表示边界的大整数。
• 已经解码成 float 还能恢复原始大整数吗？通常不能，应该回到解码入口修正 flags。
• 为什么还要使用 JSON_THROW_ON_ERROR？它能把语法错误显式抛出，避免业务代码继续处理一个误判的 null。