bcadd等bcmath函数需严格使用字符串输入、显式指定scale参数，避免浮点数传参和scale不一致导致的误差累积与性能损耗。
PHP 中用 bcadd 等 BCMath 函数做小数高频计算，确实能规避浮点误差，但「全程用」不等于「随便用」——关键在精度控制、字符串输入、运算链路一致性，否则反而引入新问题。
bcadd 等函数只接受字符串参数，传 float 会立刻失真
BCMath 所有函数（bcadd、bcmul、bcdiv 等）内部不解析浮点数，直接按字符串逐位计算。一旦你传入 0.1 + 0.2 这类原始 float，PHP 在传参前就已转成 0.30000000000000004，再喂给 bcadd 只是“精准地算错”。
- ❌ 错误写法：
bcadd(0.1, 0.2, 10)——0.1和0.2已是近似值 - ✅ 正确写法：
bcadd('0.1', '0.2', 10)—— 字符串字面量无转换损耗 - 若数值来自数据库或用户输入，确保用
(string)$val或sprintf('%.15g', $val)格式化后再进 BC 函数，避免科学计数法或尾部无效零干扰
scale 参数不是全局设置，每次调用都得显式指定
bcadd('1.234', '5.678', 2) 得到 6.91，但下一次调用 bcadd('1.234', '5.678')（漏掉第三个参数）会按默认 scale=0 截断，结果变成 6。高频计算中 scale 不一致，会导致中间结果被意外截断，误差逐层放大。
- 所有 BC 函数调用必须带
scale参数，不要依赖bcscale()全局设置 —— 它在多线程/协程环境不可靠，且容易被其他库覆盖 - 建议封装一层：比如
safe_bcadd($a, $b, $scale = 10)，内部强制校验参数类型并统一处理空值 - 除法
bcdiv尤其敏感：bcdiv('1', '3', 2)→0.33，但若后续再乘 3，bcmul('0.33', '3', 2)得0.99，而非1.00；此时需预留更高 scale（如 12）做中间计算，最后再 round 输出
高频场景下性能瓶颈不在 BCMath，而在字符串转换和内存分配
BCMath 本身是 C 实现，单次运算很快。真正拖慢高频计算的是反复的 (string) 转换、临时字符串拼接、以及大数字（如超长小数位）导致的内存拷贝。
立即学习“PHP免费学习笔记（深入）”；
- 避免在循环内做
bcadd(strval($x), strval($y), $scale)——strval()对 float 不安全，对 int 也多余 - 若数据源可控（如全来自字符串或整数），跳过类型转换；若来自 DB，用
PDO::ATTR_STRINGIFY_FETCHES => true或 MySQLi 的fetch_all(MYSQLI_ASSOC)配合字段类型声明，让数字以字符串形式取出 - 极端高频（如每秒万级）可考虑提前将常用系数转为固定字符串常量，减少运行时拼接
真正难的不是调用 bcadd，而是把整个数据流从源头到终点都锁死在字符串+确定 scale 的轨道上。少一次隐式转换，就少一处误差入口。
