php中科学计数法字符串（如"1.23e7"）用intval()或(int)转换会因float精度丢失导致静默错误；安全做法是：含e/e时用bcmath拆解计算，超长整数用gmp或bc函数，读json时启用json_bigint_as_string。
PHP科学计数法字符串直接 intval() 会丢精度
PHP里像 "1.23e7" 这种科学计数法字符串，用 intval() 或强制类型转换 (int) 会先转成 float 再截断，而 float 在大数下根本存不准。比如 "9999999999999999" 转完可能变 10000000000000000 —— 不是四舍五入，是浮点表示失效。
真正安全的做法是：先判断字符串是否含 e 或 E，再用 bcadd() / bcmul() 拆解计算，或直接走字符串解析逻辑。
- 别信
intval("1.23e7")，它等价于intval(1.23e7)，中间过了一道不靠谱的 float - 如果确定输入是合法科学计数法（如 API 返回的 JSON 数字被 PHP 自动转成字符串），优先用
floatval()+round()+strval()再转整，但仅限数字绝对值 53（即9007199254740992）以内 - 超大数（如比特币 satoshi、UUID 时间戳）必须用字符串处理：提取底数、指数，用
bcpow()和bcmul()手动算
PHP大数字字符串转 int 的三档策略
没有万能函数。选哪种方式，取决于你手上的字符串长什么样、有多大、要不要 100% 精确。
-
小数字（≤ 9007199254740991）：用
round(floatval($str))最快，但得加校验——if (abs(floatval($str)) >= 9007199254740992) { /* 切换策略 */ } -
中等长度纯数字字符串（不含 e/E，长度 ≤ 20）：正则确认全数字后，用
gmp_init($str)->gmp_intval()或bcadd($str, "0")转，比手动拆更稳 -
任意科学计数法 or 超长整数字符串（如 50 位）：必须用
bcdiv()/bcmul()模拟运算，例如"1.23e4"→ 拆成"123"和"2"（因为 1.23e4 = 123 × 10²），再用bcmul("123", bcpow("10", "2"))
json_decode() 后的数字自动变成科学计数法字符串？
不是 json_decode 的问题，是 PHP 处理大整数时的默认行为：当 JSON 中的数字超过 JSON_BIGINT_AS_STRING 阈值（默认关闭），且启用了 JSON_BIGINT_AS_STRING 选项，才会保持为字符串；否则会被转成 float，再 toString 就可能变成 "1.2345678901234567e+18"。
立即学习“PHP免费学习笔记（深入）”；
- 读 JSON 时务必加标志：
json_decode($json, false, 512, JSON_BIGINT_AS_STRING)，这样所有大整数都进字符串，避免源头失真 - 如果已拿到科学计数法字符串，别用
number_format()去“格式化”——它内部也走 float，照样崩 - 检查是否真需要 int：很多场景（如数据库写入、API 透传）其实保持字符串更安全，
mysqli_real_escape_string()和 PDO 参数绑定都支持字符串大数
为什么 (int) 和 intval() 在这里不可靠
因为它们底层都依赖 C 的 zend_strtod() → float 转换路径。一旦原始字符串表示的整数超出 float 精度范围（53 位有效二进制位），就会发生隐式舍入，且这个过程不可逆、不报错、不警告。
-
(int)"9999999999999999"→10000000000000000（实际少了 1） -
intval("1e17")→100000000000000000（看起来对，但"100000000000000001"就会错） - 哪怕加
ini_set("precision", 20)也没用——precision 控制的是输出显示，不影响底层 float 存储精度
真正要命的是：这种错误在测试数据小时完全不暴露，一到生产环境碰上真实大 ID 或金额就静默出错。最稳妥的边界意识是——只要字符串长度 > 15 或含 e/E，就别走 int 强转。
