PHP浮点数用==判断相等会出错，因IEEE 754双精度表示限制导致0.1+0.2=0.30000000000000004≠0.3；应改用abs($a - $b)

PHP浮点数直接用 == 判断相等会出错

因为 0.1 + 0.2 在 PHP（以及几乎所有语言）里不等于 0.3，而是 0.30000000000000004。这不是 PHP 的 bug，是 IEEE 754 双精度浮点数的固有表示限制。

常见错误现象：if (0.1 + 0.2 == 0.3) { ... } 永远不进分支；数据库查出来的 float 字段和 PHP 计算结果看似一样却比对失败。

• 永远别用 == 或 === 直接比较两个浮点数是否“数学上相等”
• 改用差值绝对值小于容忍误差（epsilon）： abs($a - $b)
• 业务中常用容差要结合场景定，比如金额建议用 1e-2（分），科学计算可能需 1e-15
• 注意 bcadd()、bccomp() 等 BCMath 函数不走浮点路径，但参数必须是字符串，传入 0.1 会先被转成浮点再截断——得写成 '0.1'

money_format() 和 number_format() 处理精度容易翻车

number_format() 是字符串格式化函数，不改变数值本身；money_format() 已在 PHP 8.0+ 被移除，且它底层仍依赖浮点运算，不能修复精度问题。

典型误用：用 number_format(0.1 + 0.2, 1) 得到 '0.3' 就以为“修好了”，其实中间计算仍是错的，后续再参与运算还会扩散误差。

立即学习“PHP免费学习笔记（深入）”；

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

• 显示前格式化没问题，但所有中间计算必须避开浮点——该用整数（单位：分）就用整数，该用 BCMath 就用 BCMath
• number_format() 的第二个参数是小数位数，但若原始值本身因浮点表示失真（如 19.999999999999996），四舍五入可能出人意料
• 替代方案：用 sprintf('%.2f', $val) 行为类似，同样不解决根源；真正安全的是先用 bcscale(2) + bcadd($a, $b) 再格式化

BCMath 函数传参必须是字符串，不是 float

这是最常踩的坑：bcadd(0.1, 0.2, 1) 和 bcadd('0.1', '0.2', 1) 结果完全不同。前者先把 0.1 转成浮点再转字符串，已经失真；后者才是精确路径。

错误现象：bcadd(0.1, 0.2, 1) 返回 '0.3' 看似正常，但换成 bcadd(0.1, 0.7, 1) 可能返回 '0.7'（因为 0.7 在二进制浮点中本就是近似值）。

• 所有 BCMath 函数（bcadd、bcmul、bccomp 等）只接受字符串参数，强制类型转换会立刻丢精度
• 从数据库或用户输入拿到数字后，别用 (string)$float，而要用 number_format($float, 10, '.', '') 或正则提取有效数字字符（更稳妥）
• bcscale() 设置全局小数位数，影响后续所有 BCMath 运算，但不会自动对齐输入精度——bcscale(2) 下 bcadd('1.234', '5.678', 2) 仍按原精度算，最后才截断

MySQL DECIMAL 字段和 PHP 浮点交互时精度悄悄丢失

PHP 的 MySQL 扩展（mysqli / PDO）默认把 DECIMAL 字段作为字符串返回，但很多人用 (float) 强转或直接参与运算，瞬间回到浮点陷阱。

常见场景：查出订单金额 99.99（数据库存的是 DECIMAL(10,2)），PHP 里写成 $total = (float)$row['amount'] + 0.01;，结果变成 100.00000000000001。

• PDO 默认 PDO::ATTR_STRINGIFY_FETCHES = false，但某些配置或驱动版本下可能自动转 float，务必检查 var_dump($row['amount']) 类型
• 最佳实践：保持 DECIMAL 字段始终以字符串流转，运算用 BCMath；或统一转成整数（乘 100）再算
• 如果必须用 float，至少用 round($val, 2) 截断，但仅限展示或最终输出，绝不可用于中间计算

事情说清了就结束。真正麻烦的从来不是“怎么调一个函数”，而是所有环节——输入、传输、存储、计算、输出——都得对齐精度策略，漏掉一环，前面全白干。