PHP查询返回的浮点数精度丢失，根本原因在于数据库驱动（如mysqli/PDO）将DECIMAL字段默认解析为IEEE 754浮点数，而非保留原始字符串；金额必须从连接层（PDO::ATTR_STRINGIFY_FETCHES=true）、查询层（CAST AS CHAR）、业务层（bcadd('0.29','0.71',2)）全程用字符串切断浮点污染。
直接说结论：PHP查询返回的浮点数（比如 float 类型字段）本身不是“不精确”，而是数据库（如 MySQL）在传输或 PHP 解析过程中，把本该用字符串/定点数表示的数值，强制转成了 IEEE 754 双精度浮点数——这一步就丢失了精度。金额类数据绝不能依赖这种隐式转换。
MySQL DECIMAL 字段查出来还是 float？
常见现象是：数据库字段定义为 DECIMAL(10,2)，但 PHP 用 mysqli_fetch_assoc() 或 PDO 默认模式取出来却是 float，比如 0.29 变成 0.28999999999999998。
- 根本原因在于 MySQL 协议层对
DECIMAL的处理：旧版驱动（尤其 mysqli）默认将DECIMAL当作浮点数解析，不保留原始字符串精度 - PDO 默认开启
PDO::ATTR_STRINGIFY_FETCHES = false，但若未显式设置PDO::ATTR_EMULATE_PREPARES = false，预处理语句仍可能触发浮点转换 - 验证方式：用
var_dump(gettype($row['amount']))看类型，再用printf('%.17f', $row['amount'])查看真实值
bcadd() 为什么传字符串，不能传 float？
bcadd() 等 BCMath 函数要求所有操作数必须是字符串，因为它们内部不做任何二进制浮点解析——字符串是“原始输入”，避免了从 float 到字符串的二次失真。
- 错误写法：
bcadd(0.29, 0.71, 2)—— 这两个float在传入前就已经是近似值了 - 正确写法：
bcadd('0.29', '0.71', 2)—— 字符串绕过浮点表示，直接参与十进制运算 - 注意：即使数据库返回的是字符串（如 PDO 设置
PDO::ATTR_STRINGIFY_FETCHES = true），也要确认没被自动转成float；某些 ORM 或框架中间层会偷偷 cast
从查询到计算的完整链路怎么保精度？
关键不在“用不用 BCMath”，而在“在哪一环切断浮点污染”。推荐按顺序检查：
立即学习“PHP免费学习笔记（深入）”；
- 数据库连接层：PDO 需启用
PDO::ATTR_STRINGIFY_FETCHES = true，且禁用模拟预处理（PDO::ATTR_EMULATE_PREPARES = false） - 查询层：显式
CAST(amount AS CHAR)或在 SQL 中拼接CONCAT('', amount)强制返回字符串（兼容性高） - 业务层：拿到字符串后，立刻用
bccomp($a, $b, 2) !== 0比较，而非$a == $b；加减乘除统一走bcadd/bcsub/bcmul/bcdiv - 输出层：最终结果仍是字符串，如需转整数（如单位“分”），先用
bcadd($val, '0', 0)截断小数，再(int)bcadd(...)—— 避免intval()对'28.9999999999'截成 28
最易被忽略的点：哪怕你全程用 BCMath，只要某次从数据库取出的值是 float，再转成字符串（比如 (string)$val），得到的就是失真后的字符串，比如 '0.28999999999999998' —— 后面所有 BCMath 运算都基于这个错误起点。精度保护必须从第一字节开始。
