float64聚合必然出错，因其无法精确表示十进制小数，误差累积导致sum≠expected；应改用shopspring/decimal或big.Int，并从数据源头避免float64。
直接用 float64 做聚合（求和、平均、累乘）在金融、计费、对账等场景下大概率出错——不是“可能”，是“必然”。根本原因不是代码写得不好，而是 float64 本身无法精确表示大多数十进制小数（如 0.1、0.01），误差会在多次加减中累积、放大，最终导致 sum != expected。
float64 聚合为什么越算越不准
每次加法都带入二进制舍入误差。比如 0.1 + 0.2 实际得到的是 0.30000000000000004；连续做 100 次 += 0.01，结果可能偏离 1.0 达 1e-15 量级。聚合运算（尤其是平均值：先求和再除以数量）会把这种误差传递并放大。
- 求和：误差线性累积，项数越多偏差越大
- 平均：求和误差 + 除法误差双重叠加
- 累乘：相对误差指数级增长，
math.Pow(1.01, 100)已不可信
这不是 Go 特有，而是 IEEE 754 的共性；但 Go 默认只有 float64 和 big.Int，缺少开箱即用的十进制浮点类型，所以必须主动选型。
聚合前必须决定：这是展示、存储，还是参与后续计算？
不同用途对应完全不同的精度策略：
-
仅用于日志/前端展示：用
fmt.Sprintf("%.2f", sum)或strconv.FormatFloat(sum, 'f', 2, 64)即可，不需改数据类型 - 写入数据库或配置文件（要求可逆）：必须转成字符串或整数（如“分”单位），避免浮点序列化失真
-
参与后续运算（如税率计算、阶梯计费）：绝不能用
float64，必须切换到十进制高精度库
混用场景最危险——比如把 float64 聚合结果存进 DB，再读出来做比较，等于两次误差叠加。
真正安全的聚合：用 shopspring/decimal 替代 float64
github.com/shopspring/decimal 是 Go 生态事实标准的十进制高精度库，底层用整数模拟十进制运算，无二进制舍入问题。聚合时应全程保持 decimal.Decimal 类型：
import "github.com/shopspring/decimal"
// 初始化聚合变量（非零值！）
sum := decimal.Zero
for _, v := range values {
sum = sum.Add(decimal.NewFromFloat64(v)) // 注意：NewFromFloat64 仍会带入原始误差
}
// 更稳妥：从字符串构造 → decimal.NewFromString("123.45")
avg := sum.Div(decimal.NewFromInt(int64(len(values))))
-
NewFromFloat64仅适用于输入本身已是float64且你接受其初始误差；若源头是 JSON 或用户输入，务必用NewFromString - 所有方法（
Add、Div）返回新实例，不修改原值，线程安全（但注意：内部字段非原子，goroutine 共享同一实例仍需锁） - 默认精度足够（28 位十进制），无需手动调
SetPrec，除非你明确需要更高（如科学计算）或更低（节省内存）
big.Int 聚合只适合整数，且要注意溢出和除法截断
如果聚合对象本身就是整数（如订单数、库存件数），*big.Int 是零误差选择。但两个坑必须避开：
-
big.Int.Div(a, b)是**向零截断的整除**，不是四舍五入；要算平均值，得自己补逻辑：a.Div(a, b).Add(a, big.NewInt(1)).Div(a, b)（仅适用于正数） - 从外部读取大整数时，别用
big.NewInt(int64)——它不支持超int64范围字面量；必须用new(big.Int).SetString("1234567890123456789012345", 10)并检查ok - 聚合循环中反复
new(big.Int)性能差；建议复用：tmp := new(big.Int)，每次用tmp.SetInt64(0)或tmp.Set(nil)重置
真正难的不是选哪个库，而是从第一行读取数据开始就拒绝 float64——只要业务语义是“钱”“重量”“百分比”，就该用字符串或整数建模，而不是等聚合完才发现对不上账。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
