利率计算不能用 float64，因其二进制表示导致0.035等小数存储失真（如0.034999999999999996），乘法后误差累积，百万笔对账出现“一分钱”缺口；必须用shopspring/decimal等十进制精确类型。
用 float64 做利率计算，哪怕只做一次乘法，就可能让最终结果偏差“一分钱”——这不是四舍五入问题，是底层二进制表示导致的不可逆失真，必须从数据类型和运算链路两端同时堵死。
为什么利率计算不能用 float64 直接算
利率场景（如年化 3.5%、日利率 0.009589%）天然含有多位小数，且常与本金（整数或两位小数）反复乘除。而 float64 存储 0.035 实际是 0.034999999999999996，乘以 100000 后变成 3499.9999999999995，向下取整就少 0.0000000000005 元——单笔不显，百万笔对账时就是明显缺口。
常见错误现象：
-
0.035 * 100000 == 3500返回false - 连续复利计算中，
pow(1+r, n)的误差随周期指数放大 - 用
math.Round(x*100)/100截断，但x*100本身已失真，Round 只是在错的基础上再凑一个“看起来对”的数
shopspring/decimal 是金融级利率计算的唯一合理选择
它把小数转为整数+精度位模拟十进制运算，完全绕过 IEEE 754。所有操作默认精确，无需“修复”浮点误差。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 初始化一律用
decimal.NewFromString("0.035")或decimal.NewFromInt(35).Div(decimal.NewFromInt(1000))，禁用NewFromFloat(0.035) - 利率字段在结构体中定义为
decimal.Decimal，而非float64；数据库映射时也应存字符串或整数分位，避免 ORM 自动转成 float - 复利公式
principal × (1 + r)^n要拆解：先算onePlusR := decimal.NewFromInt(1).Add(r)，再用onePlusR.Pow(n)（注意该方法需手动实现或用循环乘法，库本身不提供幂运算） - 除法必须用
DivRound(dividend, divisor, precision)显式指定小数位，比如日利率 = 年利率.DivRound(decimal.NewFromInt(365), 6)
big.Float 不适合利率计算
它本质仍是二进制浮点，只是精度可调。即便设 SetPrec(256)，输入若来自 SetFloat64(0.035)，源头已失真；而用 SetString("0.035") 初始化后，它又无法像 decimal 那样自然支持银行家舍入、固定小数位输出、JSON 安全序列化等金融刚需。
关键差异：
-
big.Float的prec是二进制位数，不是小数位；要保证 6 位小数精度，需设prec ≈ 200，远超必要 - 没有内置的
.RoundBank()或.DivRound()，每次除法后都要手动调Round()再转回，链路长、易漏 - 比较必须用
Cmp()，不能用==；而decimal.Decimal提供.Equal()方法，语义清晰
容易被忽略的精度断点
真正出问题的地方往往不在主计算逻辑，而在边界环节：
- 前端传来的利率字符串未校验格式，比如
"3.5%"或"0,035"直接塞给NewFromString会失败，但错误被静默吞掉 - 数据库读取时，如果字段是
DECIMAL(10,6)，但 driver 返回的是float64（如某些 MySQL 驱动默认行为），中间就断了一环 - 日志打印用了
fmt.Printf("%f", d)，而d是decimal.Decimal，会触发隐式转float64再格式化，日志看着对，实际值已失真 - 测试用例写
assert.Equal(t, 3500, result)，但result是decimal.Decimal，Go 会尝试转int导致 panic 或截断
