必须用BCMath函数进行金额计算。PHP浮点数存在精度问题，ThinkPHP中应将金额字段定义为string类型、数据库用DECIMAL、输入校验后以字符串传入bcadd/bcmul等函数运算，严禁使用float类型及原生算术运算符。
ThinkPHP 里用 float 做金额计算会丢精度
PHP 的 float 类型底层是 IEEE 754 双精度浮点数，0.1 + 0.2 ≠ 0.3 是常态。ThinkPHP 默认不干预数值类型，input() 或数据库读取的金额字段若被当 float 处理，加减乘除后小数位就可能多出 0.000000000000001 这类尾巴，入库或比对时直接翻车。
- 别用
floatval()、(float)强转用户输入的金额字符串，比如"19.99"→19.990000000000002 - 数据库字段必须用
DECIMAL(10,2)（或更高精度如DECIMAL(12,4)），不能用FLOAT或DOUBLE - 从
$_POST、input()拿到的金额，先用trim()去空格，再用is_numeric()校验是否为合法数字字符串，拒绝"19.99abc"这类输入
ThinkPHP 中该用 bcmul/bcadd 而不是 */+
PHP 原生算术运算符对浮点数无精度保障，而 bcmul、bcadd、bcsub、bccomp 这套 BCMath 函数专为高精度十进制计算设计，ThinkPHP 不封装它们，但你必须主动用。
- 所有涉及金额的运算——比如优惠券抵扣、分账比例计算、税费叠加——一律改用
bcadd($a, $b, 2)，第三个参数指定保留小数位数 -
bcmul("19.99", "1.06", 2)得"21.19"；而19.99 * 1.06可能得21.1894再round()就不可控 - 注意：BCMath 所有参数必须是字符串，
bcmul(19.99, 1.06, 2)会隐式转成字符串但风险高，强制写成bcmul("19.99", "1.06", 2) - 确保服务器开启
bcmath扩展（php -m | grep bcmath），否则调用直接报错Call to undefined function bcmul()
Model 层自动转 string 防止 ORM 自动 cast 成 float
ThinkPHP 的 Db 和 Model 在查出数据后，若字段类型未显式声明，可能把 DECIMAL 当 float 返回。尤其在使用 toArray() 或 JSON 输出时，19.99 变成 19.990000000000002 就完了。
- 在 Model 类中定义
protected $type = ['price' => 'string', 'total' => 'string'];，强制对应字段以字符串形式返回 - 如果用的是 ThinkPHP 6.1+，可在数据库配置里加
'strict' => true，配合'schema' => true让框架读取表结构并按DECIMAL类型自动转string - 避免在控制器里对查询结果做
(float)$data['price']这类操作，哪怕只是临时打印调试——一旦转成 float，精度就不可逆了
前端传参和接口校验必须守住字符串底线
前端 JS 的 Number 同样有浮点误差，JSON.stringify({price: 19.99}) 看似正常，但若前端用 parseFloat("19.99") + 0.01 计算后再传，后端拿到的可能已是失真值。
立即学习“PHP免费学习笔记（深入）”；
- 前端提交金额字段，一律用字符串传：{
"price": "19.99","discount": "5.00"} - ThinkPHP 接口层用
validate规则限制格式：'price|金额|require|regex:/^\d+(\.\d{1,2})?$/'，拒绝"19.999"或"19." - 不要依赖
input('price/d')这种自动转整型/浮点型的方法，改用input('price/s')显式取字符串，再交由bcadd处理 - 调试时用
var_dump(gettype($price), $price)确认是string且内容干净，比靠眼力看日志靠谱得多
最麻烦的不是不会用 bcmul，而是某次临时加个 + 0.01 忘了套函数，或者测试时用整数凑巧没暴露问题，上线后每月财务对账差 1 分钱，溯源成本远高于一开始写对。
