直接用 == 比较两个 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语言免费学习笔记（深入）”；

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 推荐写成一个辅助函数，避免重复逻辑：

  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 就完事。同一个函数，在金额校验和坐标渲染里该用的阈值可能差六个数量级。