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'就以为“修好了”，其实中间计算仍是错的，后续再参与运算还会扩散误差。
- 显示前格式化没问题，但所有中间计算必须避开浮点——该用整数（单位：分）就用整数，该用
BCMath就用BCMathnumber_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)截断，但仅限展示或最终输出，绝不可用于中间计算事情说清了就结束。真正麻烦的从来不是“怎么调一个函数”，而是所有环节——输入、传输、存储、计算、输出——都得对齐精度策略，漏掉一环，前面全白干。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
