PHP中bcmath运算结果保留字符串还是转换为float更合理？

结论优先 #

货币计算场景绝对不允许浮点数（float）参与运算或存储中间结果，最优选择是你最初写的「全程使用字符串类型+bcmath函数运算」的方案，另外两种方案都存在精度风险，不建议使用。

浮点数的核心风险 #

float是二进制浮点数，无法精确表示大部分十进制小数，比如经典的0.1 + 0.2 = 0.30000000000000004问题，只要涉及货币计算，哪怕千分之一的误差累计多了也会造成对账不平，属于业务级故障。

三个方案的优劣对比 #

• 方案1：仅bcmath运算时转字符串，其余场景用float
  完全不可行。只要你把bcmath返回的高精度字符串强制转为float，就已经可能产生精度丢失，尤其是多次累加运算后误差会被放大。相当于你用bcmath做了高精度计算，转头就把结果丢去精度更低的容器里存储，完全浪费了bcmath的能力。
  你给出的示例代码问题在于，每次循环都把bcadd的结果转成float存到$subtotal，下次运算再转回字符串，中间误差会不断累积，最终结果完全不可靠。
• 方案3：不强求严格类型，仅调用bcmath时不指定类型
  风险极高。PHP是弱类型语言，如果你不小心用了普通算术运算符（比如+/-/*）而不是bcmath函数，PHP会隐式把字符串类型的货币值转成float运算，出现精度问题后极难排查。严格类型的作用就是把问题暴露在编码/编译阶段，避免线上出了故障再回溯。
• 你最初的实现方案：全程使用字符串类型，所有运算走bcmath
  是唯一适合货币场景的方案：
  1. 数据库存储用DECIMAL(15,3)本身就是定点数，和字符串类型的精度完全匹配，读写时不要让ORM/PDO自动把DECIMAL转成float，直接读取为字符串即可。
  2. 所有货币计算全用bcmath函数，入参出参都是字符串，全程没有浮点数参与，从根本上杜绝精度丢失。
  3. 需要格式化输出给前端时，再用bcscale或者number_format处理成对应格式的字符串，不要转float后再格式化。

实操建议 #

如果目前数据库确实是用float类型存储货币，优先把字段类型改为DECIMAL(15,3)，存储层用浮点数本身就是业务风险，哪怕上层计算再精确也没用。如果使用ORM框架，给所有货币类型的字段加类型转换，读取时直接返回字符串，写入时也只接收字符串类型写入DECIMAL字段，从数据入口就切断浮点数的可能性。

内容的提问来源于stack exchange，提问作者objecttothis