直接用 == 比较两个 float64 会出错，因为 ieee 754 浮点数无法精确表示多数十进制小数（如 0.1 + 0.2 ≠ 0.3），导致舍入误差累积，应改用 math.abs(a – b)
为什么
==比较两个float64会出错因为 IEEE 754 浮点数在二进制下无法精确表示很多十进制小数（比如
0.1 + 0.2不等于0.3），直接用==判断相等大概率失败。这不是 go 特有，但 Go 的math包没提供默认的“近似相等”函数，得自己处理。常见错误现象：
0.1 + 0.2 == 0.3返回false；单元测试里断言got == want突然挂掉，而打印出来数值看起来一模一样。
- 根本原因是浮点运算累积了舍入误差，哪怕只做一次加法也可能改变最低有效位
math.Abs(a - b) 是最常用解法，但 <code>epsilon不能写死成1e-9—— 大数比较时这个阈值太松，小数又可能过严- Go 标准库不带
math.IsApprox这类函数，别指望导入就开用用
math.Abs+ 相对误差判断更稳妥绝对误差（
abs(a-b) ）适合值域集中在 0 附近的场景；相对误差（<code>abs(a-b) ）更能适应不同量级。Go 的 <code>math包里math.Abs、math.Max都可用，组合起来就是可靠基线。使用场景：金融计算中允许 0.01 元误差、物理仿真中接受 0.1% 偏差、测试断言浮点结果。
立即学习“go语言免费学习笔记（深入）”；
- 推荐写成一个辅助函数，避免重复逻辑：
func approxEqual(a, b, epsilon float64) bool { return math.Abs(a-b) <= epsilon*math.Max(math.Abs(a), math.Abs(b)) }- 若 a 和 b 可能为 0，要单独处理，否则
max(0,0)导致分母为 0 效果失效 —— 改用math.Max(math.Abs(a), math.Abs(b), 1e-12)或加分支- 注意
epsilon是无量纲比例系数，不是固定精度值；设成1e-9表示允许 10⁻⁹ 相对偏差，不是“小数点后 9 位一致”
math.Nextafter和math.Ulp能干啥
math.Nextafter返回某个浮点数向指定方向移动一个 ULP（Unit in the Last Place）后的值，是真正基于浮点数内存表示的“最小可分辨差异”。它比手算epsilon更底层、更精确，但使用门槛高、可读性差。适用场景：需要严格控制浮点误差边界（如数值库开发）、验证算法稳定性、编写高精度测试。
math.Nextafter(x, y)中 y 决定方向（y > x → 下一个更大值），常用来构造“刚好不相等”的测试用例- 没有现成的
Ulp(x)函数，但可用math.Nextafter(x, x+1) - x算出 x 附近的 ULP 值，不过要注意 x=0 或极大值时行为异常- 性能上比纯算术慢不少，普通业务代码没必要上；过度依赖它反而让逻辑难懂、难维护
测试里怎么写断言才不容易翻车
别在测试里裸写
assert.Equal(t, got, want)处理浮点数 ——testify/assert默认用==，照样崩。得显式用近似比较或自定义 matcher。使用场景：单元测试、集成测试中验证计算结果。
- 用
testify/assert.InDelta(t, got, want, delta)最省心，delta是绝对误差上限，适合已知误差范围的场景- 如果要用相对误差，
testify/assert.InEpsilon更合适，第三个参数是 epsilon（比如1e-6），内部实现就是相对误差公式- 自己封装断言时，务必把
epsilon作为参数传入，而不是硬编码在函数里；不同业务模块容忍度不同，比如风控可能要求1e-12，前端展示用1e-3就够了浮点比较真正的复杂点不在公式本身，而在误差容忍度必须和业务语义对齐——不是越小越好，也不是随便拍个
1e-9就完事。同一个函数，在金额校验和坐标渲染里该用的阈值可能差六个数量级。
