Go中float64的误差是IEEE 754二进制表示固有缺陷所致，0.1+0.2≠0.3及math.Floor(2.4/0.8)==2均源于存储失真；应避免==比较，改用容差判断，并通过fmt.Sprintf控制显示精度。
Go语言中float64的“误差”不是bug，而是IEEE 754双精度浮点表示的必然结果——0.1、0.8、math.Pi等十进制数在二进制下无法精确表达，所有后续运算都在这个近似值上进行，误差会累积、放大，但不可消除。
为什么0.1 + 0.2 != 0.3且math.Floor(2.4/0.8)返回2
根本原因是二进制表示失真：0.1在float64中实际存储为0.10000000000000000555...，0.2同理；两者相加后仍是近似值（如0.30000000000000004），自然不等于字面量0.3。而2.4和0.8各自转float64后相除，结果可能是2.9999999999999996，math.Floor向下取整得2。
- 编译器对字面量常量（如
2.4/0.8）可能做常量折叠优化，直接算出精确数学结果3.0；但运行时变量计算（如w/0.8）走的是真实浮点路径，暴露误差 -
fmt.Println(x)默认只显示约6位小数，掩盖了底层尾数差异；用fmt.Printf("%.17f", x)才能看到真实存储值 - 所有遵循IEEE 754的语言（Python/Java/C++）都存在同样问题，这不是Go特有
展示层精度控制：用fmt.Sprintf格式化，别改数值
UI输出、日志记录、调试打印等场景，只需控制显示效果，不需改变底层值。这是最轻量、最安全的做法。
- 用
fmt.Sprintf("%.2f", x)可四舍五入到2位小数（如3.333333→"3.33"） - 用
fmt.Printf("%.14f", x)能匹配多数业务对“视觉一致”的要求（如面积累加178.53981633974483） - ⚠️注意：
strconv.ParseFloat(fmt.Sprintf("%.2f", x), 64)会引入二次转换误差，且性能差，非必要不推荐
计算层精度控制：避免==比较，改用容差判断
当必须基于浮点数做逻辑分支（如“是否完成支付”“是否超阈值”），绝不能用==或!=直接比较两个float64。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是定义容差（tolerance），例如
const eps = 1e-9，然后写math.Abs(a-b) - 对金融、计费等敏感场景，容差应与业务单位对齐，比如金额用
1e-2（分），时间戳用1e-3（毫秒） - 不要用
math.Round做中间截断再比较——math.Round(2.555*100)/100可能因2.555*100本身失真而得255.499999，最终四舍五入成2.55
高精度需求场景：必须换类型，别硬扛float64
涉及金钱、汇率、科学实验数据、税务计算等，任何微小误差都不可接受，此时float64已不适用。
- 首选
github.com/shopspring/decimal：支持任意精度十进制运算，从字符串初始化（decimal.RequireFromString("28860.000000001")），避免float64中间污染 - 整数比例法更彻底：把金额存为“分”（int64）、时间存为“纳秒”（int64），全程整数运算，零误差
- ⚠️关键陷阱：不要用
decimal.NewFromFloat(0.1)——它先让0.1失真成float64，再转decimal，错误已固化
真正容易被忽略的点是：精度问题从来不是“某次计算错了”，而是“从第一个float64赋值开始，误差就已写入内存”。所以决策点不在“怎么修”，而在“要不要用”。
