bcadd传float参数结果仍错，根本原因是float在赋值时已失真（如0.29存为0.28999999999999998），转字符串后bcadd只能对错误值运算；必须全程用原始字符串输入。
因为 float 在 PHP（以及所有遵循 IEEE 754 的语言）中根本无法精确表示像 0.1、0.01、19.99 这类常见金额，误差在赋值那一刻就已发生，后续任何计算或存储都只是在错误基础上继续运算。
bcadd 传 float 参数结果还是错，为什么？
根本原因不是 bcadd() 不准，而是你传进去的参数在进函数前就失真了。PHP 把 $a = 0.29 存成二进制近似值（比如 0.28999999999999998），再转字符串就是 '0.28999999999999998'，bcadd() 再精确也只能对这个错数做运算。
- 数据库查出的
DECIMAL字段，PDO 默认可能返回float（尤其PDO::ATTR_STRINGIFY_FETCHES = false时），必须手动用(string)$row['amount']或number_format($row['amount'], 2, '.', '')转成干净字符串 - 用户输入别用
input('price/f')，强制走字符串：input('price/s') - 已有
float变量要转字符串，用number_format($f, 10, '.', '')，不用(string)$f或sprintf('%.10f', $f)（后者可能补零或截断）
round($x, 2) 能救 float 金额吗？
不能。它只对显示或临时校准“看起来像对”，但不修复底层数据污染。
-
round(0.1 + 0.2, 1)得到0.3，但0.1 + 0.2本身仍是0.30000000000000004，round()只是四舍五入这个近似值 - 若用于入库：直接
round($float * 100)再存整数，比 round 到小数安全；但前提是原始$float来自可信字符串解析，而非用户直接输的0.29字面量 - 若用于 JSON 输出：必须
json_encode(round($float * 100))，绝不能json_encode($float)—— 后者会暴露"31745.99999999999996"这种错误
MySQL DECIMAL 字段能防住 float 吗？
不能自动防。DECIMAL 是存储层保障，但 PHP 层把 float 绑定进 SQL，PDO 仍会把失真值传给 MySQL。
- 写入时：不要
$stmt->bindValue(':amt', $float, PDO::PARAM_STR)，而要用$stmt->bindValue(':amt', sprintf('%.2f', $float), PDO::PARAM_STR)或更稳妥的number_format($float, 2, '.', '') - 读取时：确认 PDO 设置
PDO::ATTR_STRINGIFY_FETCHES = true，否则DECIMAL可能被转成float返回 - 验证手段：查出来立刻
var_dump($row['amount'])，如果是float类型且值带长尾小数，说明已在读取阶段失真
最易被忽略的一点：精度污染是不可逆的。一旦某个环节用了 float（哪怕只做一次 echo 或 json_encode），这个误差就进入了系统上下文，后续所有 bc*、round、格式化都只是在掩盖，而非修正。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
