php浮点数相加不准是ieee 754双精度表示局限所致，0.1和0.2无法精确转为二进制，误差累积导致0.1+0.2=0.30000000000000004；金融计算必须用bcmath字符串运算保证十进制精度。
PHP浮点数相加为什么结果不准
PHP中0.1 + 0.2得到0.30000000000000004，不是bug，是IEEE 754双精度浮点数的固有局限。二进制无法精确表示十进制小数0.1或0.2，存储时已有微小误差，相加后误差放大，最终显示异常。
常见误判场景：
– 用==直接比较两个浮点运算结果
– 将float值存入MySQL DECIMAL字段却未格式化
– 前端传来的"19.99"被(float)强转后参与计算
什么时候该用BCMath而不是float
涉及金额、计费、金融类计算，必须用bcmul、bcadd等BCMath函数——它们基于字符串运算，不经过二进制浮点表示，可保证十进制精度。
- 所有输入必须是字符串：
bcadd('19.99', '0.01', 2)✔️；bcadd(19.99, 0.01, 2)❌（先转float再转string，误差已引入） - 第三个参数
scale控制小数位数，不是四舍五入开关，而是截断/补零依据 - BCMath不支持科学计数法，
'1e-2'会当作'0'处理 - 性能比原生浮点慢一个数量级，但金融场景下精度优先
如何安全地把用户输入转为定点数参与计算
前端传来的$_POST['amount'] = "19.99"看似干净，但若用(float)或floatval()转换，就可能埋下隐患。正确做法是跳过float中间态，直连BCMath或整型处理。
立即学习“PHP免费学习笔记（深入）”；
- 统一转为“分”存储：用
intval(round($amount * 100)→ 但注意round(19.99 * 100)可能得1998，应改用round(bcmul($amount, '100'), 0) - 更稳妥：用
filter_var($input, FILTER_SANITIZE_NUMBER_FLOAT, FILTER_FLAG_ALLOW_FRACTION)清洗后，再用bcadd($input, '0', 2)归一化小数位 - 数据库写入前，始终用
number_format($val, 2, '.', '')或bcadd($val, '0', 2)确保字符串格式合规
检查代码里是否混用了浮点与定点
最易被忽略的是“隐式类型转换”——比如把BCMath结果再赋给float变量，或在echo时被自动转为浮点显示。
- 用
gettype()和var_dump()确认关键变量类型，尤其关注bcadd()返回值——它永远是string，不是float - 警惕
+、-、*、/运算符：一旦任一操作数是float，整个表达式就退化为浮点运算 - MySQL写入时，如果字段是
DECIMAL(10,2)，但PHP传入的是float，MySQL会自行截断，且不报错——需用mysqli_stmt::bind_param('s', $val)强制字符串绑定 - 日志中打印BCMath结果时，别用
sprintf('%.2f', $val)，应直接echo $val或number_format(...)
真正难的不是选BCMath，而是让整个数据流从接收、计算到存储，全程不掉进float陷阱——哪怕只在一个中间变量里松懈一次，精度就不可逆地丢了。
