php浮点数比较出错源于ieee 754二进制近似表示，0.1+0.2≠0.3；应避免==直接比较，改用容差判断或转整数；round()对失真Float不可靠，推荐sprintf(‘%.2f’)或源头用字符串/整数保持精度。
PHP 浮点数比较为什么总是出错
因为 float 在底层是二进制近似表示，0.1 + 0.2 ≠ 0.3 —— 这不是 PHP 的 bug，而是 IEEE 754 标准的共性。直接用 == 或 === 比较两个浮点数，大概率会得到意外结果。
常见错误现象：var_dump(0.1 + 0.2 == 0.3); // bool(false)；数据库查出来的 price 字段和 PHP 计算值看似相等，if 却不进分支。
- 永远别用
==直接比较浮点数，包括从数据库、API、表单读进来的数字字符串（PHP 会自动转成float） - 比较前统一转成整数（如“分”单位）或使用容差（epsilon）判断：
abs($a - $b) - 如果必须保留小数位做逻辑判断，优先用
bcmul/bcadd等 BCMath 函数，它们是十进制精确运算
money_format 和 number_format 处理精度的差异
number_format 只是格式化输出，不改变数值本身；money_format（已废弃）同理，且在 PHP 8.0+ 不可用。它们都不能解决计算过程中的精度丢失。
使用场景：展示金额时用 number_format 没问题，但若你先 number_format($price, 2) 再拿去加减，就等于把字符串又转回了 float，白忙活。
立即学习“PHP免费学习笔记（深入）”；
-
number_format(19.999, 2)返回字符串"20.00"，但(float)"20.00"仍是浮点数，可能带误差 - 真正需要精度的场景（如扣款、对账），全程用整数（单位：分）或 BCMath：
bcadd('19.99', '0.01', 2)→"20.00" - 注意
bcadd第三个参数是小数位数，不是四舍五入位数；它会截断，不是四舍五入
从 mysql 读取 DECIMAL 字段后变 float 怎么办
MySQL 的 DECIMAL(10,2) 存的是精确十进制数，但 PHP 的 MySQL 扩展（尤其是 mysqlnd 默认配置）可能把它当作 double 返回，一读出来就失真。
常见错误现象：数据库里存的是 99.99，PHP 里 var_dump($row['price']) 显示 99.98999999999999。
- pdo 连接时加选项：
new PDO($dsn, $u, $p, [PDO::ATTR_EMULATE_PREPARES => false, PDO::MYSQL_ATTR_DIRECT_QUERY => true])，并确保PDO::ATTR_StringIFY_FETCHES是false - 更稳妥的做法：在 SQL 中显式转字符串：
select CAST(price AS char) AS price_str FROM goods，然后在 PHP 里用bcadd等处理 - mysqli 也有类似问题，开启
MYSQLI_OPT_INT_AND_FLOAT_NATIVE并配合mysqli_fetch_all(MYSQLI_ASSOC)可缓解，但不如 PDO 配置可靠
round() 四舍五入为什么有时不按预期
round() 对浮点数输入本身就有隐患：它先拿到一个已经失真的 float，再在这个失真值上四舍五入，结果自然不可靠。
例如：round(1.005, 2) 在某些系统返回 1.0 而不是 1.01，因为 1.005 实际存储为略小于它的值。
- 不要对原始
float用round()；先用string或bcadd保证输入精确，再四舍五入 - BCMath 提供
bcround的替代方案（需自己封装），比如：bcadd($val, '0.005', 2)再floor截断，但要注意这是“进一法”而非标准四舍五入 - 真要严格四舍五入到两位小数，推荐用
sprintf('%.2f', $val)—— 它底层调用 C 的printf，行为更稳定，但仍是基于float，所以仍建议源头用字符串或整数
最麻烦的地方不在函数怎么选，而在于整个数据流是否从始至终保持精度上下文：表单提交的字符串、数据库字段类型、PHP 运算方式、输出前的格式化——任一环节掉链子，前面的谨慎就白做了。