float64均值计算存在微小误差，源于二进制浮点数无法精确表示多数十进制小数，累加与除法过程持续累积并放大舍入误差；金融场景须用shopspring/decimal，以字符串初始化、手动求和再除、显式舍入。
Go语言中用float64算均值，只要涉及小数（如0.1、1.021、28860.000000001），结果就一定存在微小误差——这不是你代码写错了，而是二进制浮点表示的物理限制。
为什么float64均值计算会“莫名其妙多/少一点”
均值本质是求和后除以个数，而float64在每一步都可能引入舍入误差：
-
0.1 + 0.2不等于0.3，而是0.30000000000000004； - 像
1.021这种十进制小数，在float64里实际存的是1.0209999999999999，乘1000再转int就变成1020而非1021； - 多个
float64累加时，误差会随项数线性累积，最后除法还会再放大一次尾数偏差。
典型表现：均值结果末尾几位小数飘移（如178.53981633974483 变成 178.53981633974485），或比较 == 失败。
金融/计费类场景必须用shopspring/decimal
这是Go生态事实标准，专为十进制小数设计，不经过二进制转换：
立即学习“go语言免费学习笔记（深入）”；
- 初始化必须用字符串：
decimal.RequireFromString("1.021")，绝不用decimal.NewFromFloat(1.021)（后者已带误差）； - 求均值要手动做：先用
Sum()累加所有decimal.Decimal，再用Quo()除以int64个数； - 除法后调
.Round(2)控制小数位，不是靠格式化输出掩盖问题； - 全程避免任何
float64中间变量，否则高精度链立刻断裂。
科学计算或日志展示可用math.Abs(a-b) 代替<code>==
当必须用float64且需判断均值是否“足够接近”某个值时：
- 容忍度
tolerance通常设为1e-9（单精度）或1e-14（双精度），具体看业务允许偏差； - 不要用
math.Round(x*100)/100做四舍五入——x*100本身可能已是1020.9999999999999； - 若仅用于打印，用
fmt.Printf("%.14f", mean)可视觉对齐，但底层值不变，不可用于后续逻辑分支。
整数比例法最轻量，适合金额、时间戳等可换算场景
把原始单位放大（如元→分、秒→毫秒），全程用int64运算：
- 输入是字符串时，先用
strconv.ParseInt("1021", 10, 64)解析为“分”，再求和、除法； - 均值结果再除以100转回“元”，余数决定是否进位；
- 零依赖、无GC压力、性能最高，但要求业务数据天然支持离散化（比如不能处理
0.001分这种需求）。
真正麻烦的从来不是“怎么算”，而是“什么时候该放弃float64”——一旦涉及钱、配置阈值、状态判定，就得立刻切到decimal或整数路径。犹豫一秒，线上就可能少一分钱。
