Hyperf 必须全程使用 BCMath 字符串运算处理高精度数值，因 PHP 浮点数固有误差会导致金融计算必然出错；需关闭 PDO 模拟预处理、禁用自动类型转换，确保数据库 DECIMAL 字段以字符串形式直达业务层，再调用 bcadd 等函数运算。
Hyperf 默认用 PHP 原生浮点数（float）处理数值，一旦涉及金融、科学计算或高精度聚合（比如累计金额、汇率换算、统计均值），0.1 + 0.2 !== 0.3 这类误差会直接穿透到业务层——不是“可能出错”，而是“必然出错”。BCMath 是唯一被 PHP 官方长期维护、无依赖、纯字符串运算的高精度扩展，必须启用并贯穿整个数据链路。
为什么不能只在最后一步用 bcadd()
常见误区是：数据库查出 float，等要加总时再用 bcadd()。这已经晚了——从 MySQL 返回的那一刻起，精度就丢失了。例如：SELECT 0.1 + 0.2 在 MySQL 中返回的是 0.30000000000000004（取决于协议和驱动），PHP 接收后自动转成 float，bcadd('0.30000000000000004', '0') 无法还原真实值。
- MySQL 的
DECIMAL字段在 PDO 中默认映射为string，但 Hyperf 的Db组件若未显式配置，会触发类型转换逻辑，悄悄转成float - ORM 查询结果中的数字字段，若没关掉自动类型转换，也会走一遍
(float)强转 - 哪怕你手动
bcadd()一百次，输入源错了，结果全错
强制 PDO 返回字符串 + 关闭 Hyerf 自动类型转换
核心是让数字从数据库出来就保持字符串形态，不经过任何 float 中转。Hyperf 使用 PDO，默认开启 PDO::ATTR_STRINGIFY_FETCHES，但这个开关只影响非数字类型；真正关键的是关闭 PDO::ATTR_EMULATE_PREPARES 并设置 fetch_mode 为字符串优先。
- 在
config/autoload/db.php中，给对应数据库连接增加配置：'options' => [ PDO::ATTR_EMULATE_PREPARES => false, PDO::MYSQL_ATTR_COMPRESS => true, ], 'fetch_mode' => PDO::FETCH_ASSOC, - 确保 MySQL 字段定义为
DECIMAL(18,6)或类似精确类型，而非FLOAT/DOUBLE - 查询后，直接用
bcadd()、bcmul()等函数操作字符串值：$row = $this->db->query("SELECT amount FROM orders WHERE id = ?", [$id])->fetch(); // $row['amount'] 是字符串，如 "199.99" $total = bcadd($row['amount'], '0.01', 6); // 第三位是小数位数
封装 BCMath 工具类避免重复写精度参数
每次调用 bcadd($a, $b, 6) 写死小数位易出错。建议封装一层，把精度规则绑定到业务语境：
- 创建
app/Helper/BcHelper.php：class BcHelper { public static function moneyAdd(string $a, string $b): string { return bcadd($a, $b, 2); } public static function rateMul(string $value, string $rate): string { return bcmul($value, $rate, 6); // 汇率保留6位 } } - 不要试图在模型中重载
__get自动转 BC —— 会污染所有数字字段，且无法区分金额、数量、比率等不同精度需求 - 对外 API 返回前，用
number_format((float)$val, 2, '.', '')转回标准格式（仅限展示），内部全程用字符串
最易被忽略的一点：BCMath 函数所有参数必须是字符串，连 '0' 都不能写成 0。传入整数或 float，函数会先转成字符串，但转换过程已失真。只要看到 bc* 函数里出现数字字面量或变量没加引号，精度防线就塌了。
