php大整数加减法不能直接用+ -运算符，因int类型受平台限制，超限后转float导致精度丢失；必须用bcmath函数并传字符串参数，且需确保输入无损、扩展已启用、scale设为0。
PHP大整数加减法为什么不能直接用+ -运算符
因为PHP的int类型有平台限制（32位系统最大约21亿，64位约9×10¹⁸），超出就自动转成float，精度丢失——比如999999999999999999 + 1在很多环境下会变成1000000000000000000甚至1e+18，结果错得悄无声息。
常见错误现象：var_dump(999999999999999999 + 1); 输出 float(1000000000000000000)；用==比较两个“看似相等”的大数返回false；数据库读出的bigint字段一参与运算就变样。
根本原因不是PHP笨，而是它默认按C语言整型规则走，没把“任意精度整数”当第一公民。所以必须显式切换到高精度上下文。
bcmath加减法必须传字符串参数
bcmul、bcadd、bcsub这些函数只接受string，传整数或float会触发静默截断或科学计数法转换，直接引入误差。
立即学习“PHP免费学习笔记（深入）”；
使用场景：处理订单ID、区块链nonce、长ID拼接、金融类累计值等明确超过PHP_INT_MAX的数值。
实操建议：
- 所有输入先强制转
(string)，别信strval()或sprintf('%s', $x)——它们对float输入仍可能输出1.23e+15 - 用
is_numeric($x) && (string)(int)$x === (string)$x粗筛是否“能无损转整串”，否则直接拒绝 - 从MySQL读
BIGINT时，PDO务必设PDO::ATTR_STRINGIFY_FETCHES => false，否则自动转string反而省心；但若开启PDO::ATTR_EMULATE_PREPARES，注意驱动可能悄悄转回int
bcadd和bcsub的scale参数不是可选摆设
第三个参数$scale控制小数位数，但对纯整数运算也起作用：它决定结果末尾是否补零、以及进位逻辑是否激活。设为0最安全，设为空或不传会继承全局bcscale()设置——而这个全局值可能被其他模块污染。
性能影响：scale越大，计算越慢，内存占用越高；但整数场景下设0几乎无开销。
示例对比：
bcadd('999999999999999999', '1', 0); // 正确返回 '1000000000000000000'
bcadd('999999999999999999', '1'); // 依赖当前bcscale()，风险高
bcadd('100', '50', 2); // 返回 '150.00'，整数运算一般不需要
别忘了检查bcmath扩展是否启用
很多Docker镜像或共享主机默认不启bcmath，调用bcadd直接报Fatal error: Uncaught Error: Call to undefined function bcadd()。
实操建议：
- 部署前跑
php -m | grep bcmath或extension_loaded('bcmath') - 函数调用前加
function_exists('bcadd')兜底，避免线上崩 - 替代方案极有限：自己写字符串竖式加减太重；GMP扩展虽快但不支持负数运算（
gmp_add要求非负），且部分环境没装
真正麻烦的从来不是写对一行bcadd，而是确保从HTTP请求、数据库、缓存、日志里捞出来的每个数字，都没在某个环节被PHP自动转成float又塞进bc函数里。
