bcdiv()做除法时必须传字符串参数并显式指定scale，否则精度误差更隐蔽；因其底层为十进制字符串模拟手算，不依赖IEEE 754浮点，可真正控制精度边界。
直接说结论：用 bcdiv() 做除法时，如果结果要参与后续计算（比如加减、入库、比对），必须传字符串参数 + 显式指定小数位，否则精度误差照旧，甚至更隐蔽。
为什么 bcdiv('10', '3', 2) 比 10 / 3 可靠
普通除法 10 / 3 得到的是双精度浮点数 3.3333333333333335，它在内存里是二进制近似值；而 bcdiv() 是十进制高精度运算，底层不依赖 IEEE 754 —— 它把输入当字符串逐位模拟手算，所以能真正控制精度边界。
常见错误现象：
-
bcdiv(10, 3, 2)：传数字，PHP 先算出3.3333333333333335再交给bcdiv()截断，结果仍是失真值 -
bcdiv('10', '3', 0)：返回'3'（向下截断），不是四舍五入，容易低估 -
bcdiv('10', '3', 10)：返回'3.3333333333'，但若后续再用bcadd()加另一个数，小数位不一致会引发隐式补零或截断
bcdiv() 的三个参数怎么设才不出错
关键不是“想保留几位”，而是“业务要求几位 + 后续怎么用”：
立即学习“PHP免费学习笔记（深入）”；
- 第一个参数（被除数）和第二个参数（除数）必须是字符串，例如
'100.00'、'12'，不能是100.00或(string)100.00（后者仍可能先失真） - 第三个参数（小数位数）建议统一配置，比如金融场景固定用
2；不要临时写bcdiv($a, $b, 2)又在别处写bcdiv($c, $d, 4)，后续加总时得反复调bcscale() - 如果除不尽且需四舍五入（比如分润计算），
bcdiv()本身不四舍五入，得手动套round()或先多算一位再截断：bcdiv('10', '3', 3)→'3.333'，再用bcadd('3.333', '0.0005', 2)模拟进位
和 round(10/3, 2) 的本质区别在哪
round() 是对一个已经失真的浮点数做显示修正，治标不治本：
-
round(0.29 * 100, 0)还是可能得28，因为0.29 * 100算出来就是28.999999999999996 -
bcdiv('29', '100', 2)输入是精确的'29'和'100'，输出'0.29'，全程无二进制介入 - 性能上，
bcdiv()比浮点除法慢一个数量级，但金融、对账等场景不该省这点 CPU
容易被忽略的坑：MySQL 读出来的 DECIMAL 变成 float
即使数据库存的是 DECIMAL(10,2)，PDO 默认可能把它转成 PHP float 返回，一读就失真。验证方法：var_dump($row['amount']) 看是不是 float(99.99) 而不是 string('99.99')。
解决办法只有两个靠谱的：
- PDO 连接时加选项：
PDO::ATTR_EMULATE_PREPARES => false+PDO::ATTR_STRINGIFY_FETCHES => false，并确认驱动是 mysqlnd - SQL 层强制转字符串：
SELECT CAST(amount AS CHAR) AS amount_str FROM orders，然后在 PHP 里用bcdiv($row['amount_str'], '100', 2)
别信 number_format() 或 sprintf() —— 它们只改输出，不改底层值；也别依赖 ini_set('serialize_precision', -1)，它只影响 json_encode() 和序列化，不影响计算过程。
