必须用整数（分）或decimal.js处理金额计算，因Number存在浮点误差；toFixed仅格式化不修复精度；前端展示可用toFixed(2)，但中间运算须全程用分或Decimal字符串运算。
直接结论：别用 Number 做中间计算，所有金额必须转成整数（分）再运算，或用 decimal.js 封装字符串计算。
为什么 toFixed(2) 不能修金额精度
它只是对已存在的浮点数做格式化，不修复底层误差。比如 (1.005).toFixed(2) 返回 "1.00"，因为 JS 实际存的是 1.00499999999999989；更隐蔽的是 2.9 * 1850 得到 5364.999999999999，.toFixed(2) 后是 "5365.00"，看起来对了，但数值本身仍是错的——后续参与加减、校验、签名时会暴露问题。
- 前端展示可用
toFixed(2)，但仅限最终渲染，不可用于中间值 - 任何涉及比较（如
===）、聚合（如reduce求和）、传参（如支付接口）的金额，都必须是精确值 - 微信小程序里
parseFloat('1.005')在旧基础库中可能额外失真，不能依赖字符串解析兜底
最稳方案：全程用「分」为单位做整数运算
把所有金额（单价、数量、运费、优惠）统一乘以 100 转成整数，运算全程只用 Math.round 或直接 +/-/*，最后除以 100 显示。这是金融系统通用做法，零误差、无依赖、多端一致。
- 后端接口返回金额字段建议直接给「分」，避免前端转换出错
- 前端接收时立刻转整数：
const priceInCents = Math.round(parseFloat(item.price) * 100) - 购物车总价计算示例：
cart.items.reduce((sum, i) => sum + Math.round(i.price * 100) * i.qty, 0) - 显示时再转回元：
(totalCents / 100).toFixed(2)—— 此时除法结果已是精确小数，toFixed安全
需要小数参与运算？用 decimal.js 替代原生 Number
当业务逻辑复杂（如满减叠加、阶梯折扣、汇率换算），硬转整数会增加条件分支和单位换算成本，这时应引入 decimal.js。注意小程序不支持 npm install，需手动拷贝 decimal.js 或 decimal.js-light 到项目中。
- 所有数字必须以字符串传入：
new Decimal('2.9').times('1850')，不能写new Decimal(2.9) - 避免混用：
Decimal.add(a, b)可以，但a.plus(b)更直观；不要在中间步骤转回Number - H5 和 App 端可直接 npm 引入；小程序需将
dist/decimal.min.js放入static/，然后import { Decimal } from '@/static/decimal.min.js' - 性能影响小，单次运算耗时在微秒级，购物车实时计算完全无压力
容易被忽略的坑：后端没对齐，前端再准也没用
前端用整数算得再稳，如果后端数据库字段是 DECIMAL(10,2) 却用浮点数插入，或 PHP 的 bcadd 参数顺序写反，金额就已在源头失真。务必确认：
- 后端入库前是否也做了「元→分」转换？还是直接存了
floatval($_POST['amount'])？ - 前后端金额字段命名是否明确区分单位？比如
amount_yuanvsamount_cents，别用模糊的price - 订单对账时比的是字符串还是数字？
'100.00' === '100.00'安全，100.00 === 100不安全
