PHP浮点数精度问题根源在于IEEE 754二进制表示无法精确表达多数十进制小数，因此必须从源头规避：BCMath需传字符串（如bcadd('0.1','0.2',1)），GMP适用于整数单位（如“分”），PHP 8.2+ Decimal扩展则要求new Decimal('0.29')而非float变量。
PHP浮点数精度问题无法靠四舍五入或类型转换“修好”，必须从数据源头切断二进制表示路径——要么用字符串走BCMath，要么用整数单位（如“分”），要么升级到PHP 8.2+用Decimal。
bcadd等BCMath函数为什么必须传字符串？
因为bcadd、bcsub等函数不接受float类型参数。如果你写bcadd(0.1, 0.2, 1)，PHP会先把0.1和0.2转成float，此时已经失真（变成0.10000000000000001这类值），再转成字符串传给BCMath，等于白用。
- 正确写法是
bcadd('0.1', '0.2', 1)，引号包裹确保原始十进制字面量不被污染 -
bcscale(2)只影响后续未指定$scale的运算，但不会自动对齐输入；bcadd('1.234', '5.678', 2)仍按原精度计算，最后截断到2位小数 - 除法
bcdiv必须显式传$scale，否则默认返回0位小数（即整数部分）
round()、number_format()、sprintf()为什么不能解决精度根源？
它们操作的是**已经失真的float值**。比如$x = 0.29 * 100实际是28.999999999999996，round($x)是在这个错误值上四舍五入，结果可能仍是28；number_format($x, 0)同理，底层仍基于失真float做格式化。
-
sprintf('%.2f', $val)只是格式化输出，不改变变量本身精度 -
number_format()第二个参数控制小数位，但若输入float本身因二进制表示失真（如19.999999999999996），四舍五入可能跳变 - 真正安全的路径是：先用
bcadd('19.99', '0.01', 2)得'20.00'，再echo或sprintf输出
PHP 8.2+的Decimal扩展怎么避免踩坑？
Decimal是唯一能像原生float一样写代码却保持十进制语义的方案，但它对输入极其敏感：一旦传入float变量，就前功尽弃。
立即学习“PHP免费学习笔记（深入）”；
- ✅ 正确：
new Decimal('0.29')、Decimal::fromString('19.99') - ❌ 错误：
new Decimal(0.29)——0.29在传入前已被转为失真float - 运算符重载可用：
(new Decimal('0.1'))->add(new Decimal('0.2')) === new Decimal('0.3') - 检查是否可用：
class_exists('Decimal\Decimal')，不是extension_loaded('decimal')
什么时候该用GMP而不是BCMath？
GMP性能远高于BCMath，但只支持整数。如果你的业务天然适合整数建模（比如金额单位统一为“分”），GMP就是更优解。
- 把
19.99元存为1999（单位：分），全程用gmp_add、gmp_mul等处理 - 需要小数结果时，最后一步用
bcdiv(gmp_strval($result), '100', 2)定点缩放 -
gmp_init('9223372036854775807')可安全处理超大整数，而BCMath字符串长度受限于内存
最容易被忽略的一点：所有高精度方案都要求**输入可控**。如果用户提交的是带逗号的"14,94"，直接喂给bcadd会得到'14'（PHP字符串转数字时遇逗号截断）。必须先str_replace(',', '', $input)或用filter_var($input, FILTER_SANITIZE_NUMBER_FLOAT)清理，再确认是否为有效数字字符串——精度计算的第一道防线，永远在数据进入计算逻辑之前。
