Go math/big 如何控制数值精度

我第一次把 math/big 接到金额比例和测量数据的计算链路时，最容易误判的一件事是：打印出了很多小数，并不代表计算真的保留了那么多有效信息。Go 的 big.Float 精度按二进制尾数位数计算，真正要控制的是结果接收者的 SetPrec、舍入模式和误差状态。

实用结论是：先用 SetPrec 给每个关键结果设预算，再用 SetMode 明确舍入方向，运算后通过 Acc() 或转换返回的 Accuracy 判断是否发生舍入。若业务要精确保存分数，优先考虑 big.Rat；若只处理整数，继续使用 big.Int，不要为了“更高精度”全部换成浮点。

我先把“精度”与“显示位数”分开

big.Float 的 Prec() 返回尾数可用的二进制位数，不是十进制小数位。比如设置 128 位，表示计算过程给尾数约 128 个二进制位的空间；最终用 fmt 打印多少位，是另一件事。只改 %.2f 不会修复已经发生的舍入。

这一步很重要：big.Rat 的 1/3 可以一直保留为分数，转成 big.Float 后才会面对位数和舍入问题。我的经验是先按数据的“最终边界”选类型，而不是看到数字很大就统一使用 big.Float。

创建值时就设置位数预算

精度要落在结果对象上。下面的写法把十进制文本解析到 128 位的 big.Float，并打印实际精度和结果。代码里的注释只保留关键判断，方便把示例改成业务函数。

package main

import (
    "fmt"
    "math/big"
)

func main() {
    // 128 是尾数二进制位数，不是保留 128 位小数。
    x, _, err := big.ParseFloat("0.1", 10, 128, big.ToNearestEven)
    if err != nil {
        // 解析失败时停止使用半成品，避免把零值继续传入计算。
        panic(err)
    }

    y := new(big.Float).SetPrec(128).SetFloat64(0.2)
    sum := new(big.Float).SetPrec(128)
    // 接收者 sum 决定本次结果按多少位尾数舍入。
    sum.Add(x, y)

    fmt.Printf("prec=%d value=%.20f accuracy=%s\n", sum.Prec(), sum, sum.Acc())
}

要注意 NewFloat 或 SetFloat64 的输入本身已经是二进制浮点值。如果输入来自用户、配置或账单文本，我会优先使用 ParseFloat 或 SetString，不要先经过 float64 再“转回高精度”。

图1：big.Float 精度预算和结果接收者的静态关系示意图，不是真实运行截图。

舍入模式要和业务方向一致

默认舍入模式是 ToNearestEven。它适合一般数值计算，但金额上取整、容量上限、风险估算等场景往往需要向下或向上舍入。模式属于 Float 的状态，设置后会影响后续产生结果的操作。

func roundForLimit(input string) (*big.Float, error) {
    // 向正无穷取整适合“不能低估上限”的示例；实际规则要由业务确认。
    f, _, err := big.ParseFloat(input, 10, 64, big.ToPositiveInf)
    if err != nil {
        // 返回原始解析错误，让调用方决定是否提示或回退。
        return nil, err
    }
    return f, nil
}

func main() {
    f, err := roundForLimit("2.1")
    if err != nil {
        panic(err)
    }
    fmt.Println(f)
}

不要把舍入模式和格式化混为一谈。格式化只影响展示；SetPrec 和 ParseFloat 的精度、模式才影响数值状态。若中途需要改变模式，先明确这是新阶段的计算边界，并在记录中保留该选择。

用 Accuracy 检查“看起来很准”的结果

Acc() 表示最近一次产生这个 Float 的操作相对精确值的方向：Exact 表示精确，Below 表示结果在精确值下方，Above 表示在上方。把 Float64() 的第二个返回值也接住，才能知道窄化转换有没有损失。

func toFloat64(x *big.Float) (float64, error) {
    // 转成机器浮点前保留 Accuracy，不能只拿第一个返回值。
    value, acc := x.Float64()
    if acc != big.Exact {
        // 这里把舍入当作显式状态交给上层，而不是静默吞掉。
        return value, fmt.Errorf("float64 conversion is %s", acc)
    }
    return value, nil
}

这个检查并不意味着每次非 Exact 都必须失败；它只是把决策点显式化。报表展示可以接受 Below 或 Above，计费、阈值和比较逻辑则应根据方向采取保守策略。

图2：SetPrec、舍入模式、运算结果和 Accuracy 的静态关系示意图，不是真实运行截图。

最后按边界控制成本

精度越高，数值对象和运算成本通常越高，而且每个运算结果都可能复用接收者的内存。我的做法是把高精度限制在核心计算段：输入阶段保持文本或 Rat，需要实数算法时转成统一精度的 Float，输出前再做一次明确的转换检查。

如果看到结果异常，按这个顺序查：是否提前经过 float64；结果接收者是否还是零精度；是否在中途调用了 SetPrec 导致重新舍入；舍入模式是否符合业务；最后再看 Acc() 和窄化转换的 Accuracy。这样查出来的通常不是“math/big 溢出”，而是精度预算和类型边界没有被写清楚。

小结

math/big 控制数值精度的核心不是多打印几位，而是让精度、舍入和误差成为代码里的状态：SetPrec 设定位数，SetMode 规定方向，Acc 负责复查。如果问题本质是精确分数或大整数，就分别使用 big.Rat 和 big.Int，不要让 big.Float 承担不适合它的任务。