bcadd结果错误的根本原因是输入参数未用字符串字面量，如bcadd($a, $b, 2)中$a、$b为float已失真；正确做法是全程使用原始字符串，包括数据库decimal字段读取、用户输入强制取字符串、json输出前格式化。
bcadd 必须传字符串，否则精度在进函数前就丢了——这是 ThinkPHP 里金额计算出错最常踩的坑。
ThinkPHP 中用 bcadd 做金额加法，为什么结果还是不对？
因为你在控制器或模型里写了类似 bcadd($a, $b, 2)，而 $a 和 $b 是从数据库查出来的 float 字段，或者来自 input() 的原始数字。PHP 已经把 0.29 存成 0.28999999999999998，再转字符串就是 '0.28999999999999998'，bcadd 再准也救不回来。
正确做法是：所有进入 bc* 函数的数值，必须是「原始字符串」。
- 数据库字段用
DECIMAL(10,2)，查出来仍是字符串（PDO 默认启用PDO::ATTR_STRINGIFY_FETCHES = false时例外，需手动处理） - 用户输入用
input('price/s')强制取字符串，别用input('price/f') - 已有 float 变量要转字符串，用
number_format($float, 10, '.', '')，不用(string)$float或sprintf('%.10f', $float)（后者可能补零失真）
bcscale(2) 设了全局精度，为什么 bcadd('1.234', '5.678', 2) 还是算出 '6.91' 而不是 '6.92'？
bcscale() 只影响「未显式传 $scale 参数」的调用，它不改变输入值精度，也不强制中间过程四舍五入。上面例子中，bcadd('1.234', '5.678', 2) 显式指定了 $scale = 2，所以是先算出完整和 '6.912'，再按默认舍入模式（BC_ROUND_HALF_UP）截到两位小数 → '6.91'。
如果你想要银行家舍入或向上进位，得显式传 $mode：
-
bcadd('1.234', '5.678', 2, BC_ROUND_HALF_EVEN)→'6.91' -
bcadd('1.234', '5.678', 2, BC_ROUND_HALF_UP)→'6.91'（因第三位是 2） -
bcadd('1.235', '5.675', 2, BC_ROUND_HALF_UP)→'6.91'（1.235 + 5.675 = 6.910，第三位是 0）
ThinkPHP 模型写入金额字段前，不校验字符串格式会怎样？
直接赋值 $model->amount = 0.29;，然后 save()，即使数据库是 DECIMAL，TP 也可能触发隐式转换：PHP 把 0.29 当 float 处理，MySQL 收到的是近似二进制值，入库后存成 0.28999999999999998 —— 后续任何 bc* 计算都晚了。
安全写法：
- 模型定义
protected $type = ['amount' => 'decimal'];（TP6+ 支持） - 写入前强转：
$model->amount = number_format($input, 2, '.', ''); - 或统一走验证器：
['amount' => 'require|number|regex:/^\d+(\.\d{1,2})?$/']，确保是合规字符串
JSON 返回金额字段时，json_encode 又把精度搞丢了怎么办？
TP 默认用 PHP 原生 json_encode，而它对 float 的序列化受 serialize_precision 配置影响。即使你数据库存的是 29.00，查出来是 float，json_encode 可能输出 "28.999999999999996"。
解决路径只有两条：
- 改配置：php.ini 中设
serialize_precision = -1（推荐），或运行时ini_set('serialize_precision', '-1') - 手动转字符串：返回前对金额字段做
number_format($val, 2, '.', '')，再塞进数组
注意：TP 的 toJson() 不自动处理这个，得自己 wrap 一层。
bcmath，而是从请求入口、数据库读写、到 JSON 输出，每一环都可能悄悄把字符串变成 float 再变回字符串——而那个“悄悄”，往往只在月底对账时才露头。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
