Go math.Round 遇到半数时为什么远离零取整

Go 的 math.Round 定义就是“就近取整，恰好位于两个整数中间时远离零”。所以 math.Round(2.5) 得到 3，math.Round(-2.5) 得到 -3；负数半数不会得到 -2，因为 -3 离零更远。

官方文档：https://pkg.go.dev/math#Round

标准库源码：https://go.dev/src/math/floor.go

我第一次踩坑的是 -2.5

我第一次认真核对这个规则，是在一组正负对称数据的单元测试里。测试把“5 入”理解成了永远向正方向进一位，于是期望 -2.5 变成 -2；标准库实际返回 -3。问题不在 Go 特殊处理负数，而在“向上取整”和“远离零”被混成了同一个概念。

math.Round 先选最近的整数。只有在距离完全相同的半数位置，才使用远离零作为决胜规则。对 2.5 来说，候选是 2 和 3，远离零的是 3；对 -2.5 来说，候选是 -2 和 -3，远离零的是 -3。

先用六组基线值确认规则

遇到舍入问题，我更愿意先列基线，不凭“常见四舍五入”的印象判断。下面六个值把半数两侧和正负号都覆盖了：

package main

import (
    "fmt"
    "math"
)

func main() {
    values := []float64{2.49, 2.5, 2.51, -2.49, -2.5, -2.51}
    for _, value := range values {
        // 同时打印输入和结果，正负半数能放在一张表里核对。
        fmt.Printf("Round(%5.2f) = %2.0f\n", value, math.Round(value))
    }
}

官方源码注释直接写明“rounding half away from zero”。标准库还明确了特殊值：正负零保持正负零，无穷大保持无穷大，NaN 仍然是 NaN。

为什么负数是减 1

理解源码时，不必先钻进位操作。Go 源码给出了一段等价规则：先用 Trunc 截掉小数部分，再看原值与截断值的距离；距离至少为 0.5 时，按原数符号补一个 1。

func roundRule(x float64) float64 {
    // Trunc 始终朝零截断：2.5 变 2，-2.5 变 -2。
    t := math.Trunc(x)
    if math.Abs(x-t) >= 0.5 {
        // Copysign 把 1 改成与 x 同号，因此负数会减 1。
        return t + math.Copysign(1, x)
    }
    return t
}

把 -2.5 代入即可：截断值是 -2，距离是 0.5，Copysign(1, -2.5) 得到 -1，最终是 -3。标准库真正实现使用浮点位操作以覆盖性能和特殊值，但语义与这段规则一致。

这也解释了为什么不能用 math.Floor(x + 0.5) 代替全部情况。这个表达式对部分正数看起来正确，却没有按同一规则处理负半数、极大值和特殊值。

RoundToEven 到底差在哪里

math.RoundToEven 也选择最近整数，但半数时选择相邻的偶数。它不是“总向零”或“总远离零”，而是由候选整数的奇偶性决定。

func compareHalf(values []float64) {
    for _, value := range values {
        // 同一个输入同时经过两种规则，差异只在半数边界显现。
        away := math.Round(value)
        even := math.RoundToEven(value)
        fmt.Printf("x=%4.1f away=%4.0f even=%4.0f\n", value, away, even)
    }
}

选择哪一个不能只看函数名。接口协议、报表规则或统计口径明确要求哪种舍入，就使用哪种；若规则没有写清，应先把半数行为写进需求和测试，再落代码。

用 Nextafter 测半数边界

十进制文本里的“刚好小一点”和“刚好大一点”不容易精确构造。math.Nextafter 可以得到朝指定方向相邻的可表示 float64，很适合验证半数边界。

func TestRoundAroundHalf(t *testing.T) {
    below := math.Nextafter(2.5, 0)
    above := math.Nextafter(2.5, math.Inf(1))

    tests := []struct {
        name string
        in   float64
        want float64
    }{
        // 三个值分别位于半数下方、半数本身和半数上方。
        {name: "below-positive-half", in: below, want: 2},
        {name: "exact-positive-half", in: 2.5, want: 3},
        {name: "above-positive-half", in: above, want: 3},
        // 负半数朝零的一侧应得到 -2，精确半数得到 -3。
        {name: "toward-zero-negative", in: math.Nextafter(-2.5, 0), want: -2},
        {name: "exact-negative-half", in: -2.5, want: -3},
        {name: "away-negative-half", in: math.Nextafter(-2.5, math.Inf(-1)), want: -3},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := math.Round(tt.in); got != tt.want {
                // 报错时保留足够精度，避免十进制格式掩盖相邻浮点数。
                t.Fatalf("Round(%0.17g)=%v, want %v", tt.in, got, tt.want)
            }
        })
    }
}

这组测试比只测 2.5 更有价值：它能确认代码是在判断“最近值”，而不是见到某个十进制尾数就机械进位。负数也单独覆盖，能防止实现者把“远离零”误写成“向正无穷”。

正负零、无穷大和 NaN 怎么测

特殊值通常不是业务主路径，但通用数值函数应明确处理。不能用普通等号判断 NaN，因为 NaN 与任何值（包括自身）比较都不相等；检查负零则要看符号位。

func TestRoundSpecialValues(t *testing.T) {
    negativeZero := math.Copysign(0, -1)

    // Round 应保留负零的符号位。
    if got := math.Round(negativeZero); !math.Signbit(got) {
        t.Fatalf("Round(-0) lost the sign bit")
    }

    // 正负无穷大保持不变。
    if got := math.Round(math.Inf(1)); !math.IsInf(got, 1) {
        t.Fatalf("Round(+Inf)=%v", got)
    }
    if got := math.Round(math.Inf(-1)); !math.IsInf(got, -1) {
        t.Fatalf("Round(-Inf)=%v", got)
    }

    // NaN 必须使用 IsNaN 判断，不能写 got == math.NaN()。
    if got := math.Round(math.NaN()); !math.IsNaN(got) {
        t.Fatalf("Round(NaN)=%v", got)
    }
}

对普通业务程序，最重要的是决定这些值能否进入后续流程。若输入来自外部计算或传感数据，常见做法是在舍入前先拒绝 NaN 和无穷大，而不是让它们一直传到序列化、数据库或统计层。

保留小数位不能只盯着 Round

常见写法是先乘以 10 的幂，取整后再除回去。它可以用于容许浮点误差的显示或工程计算，但不能让十进制小数自动变得精确，因为 float64 以二进制表示，很多十进制小数在进入 Round 前已经落在理论半数的某一侧。

func roundPlaces(x float64, places int) float64 {
    // 该辅助函数只适合业务允许 float64 误差的场景。
    scale := math.Pow10(places)
    return math.Round(x*scale) / scale
}

func printWithPrecision(x float64) {
    // 用足够多的有效数字观察实际存储值，而不是只看格式化后的两位小数。
    fmt.Printf("stored=%0.17g rounded=%0.2f\n", x, roundPlaces(x, 2))
}

另一个边界是缩放溢出：小数位过大或输入绝对值很大时，x*scale 可能变成无穷大，除回去也无法恢复。通用函数应限制 places，并在舍入前后检查 math.IsInf 与 math.IsNaN。

小数位、金额和统计要分开选

我现在不会把“需要两位小数”直接翻译成 math.Round(x*100)/100，而是先问数据属于哪个领域。显示值、测量值、金额和统计聚合对误差与舍入偏差的要求不同。

math.Round 本身没有“错误”，它只是执行了非常明确的规则。真正容易出问题的是业务没有先定义规则，或者把浮点表示误差、显示格式和数值舍入混为一谈。

一份够用的测试清单

• 同时覆盖正数、负数和零。
• 对每个半数覆盖下方、精确半数和上方三个值。
• 若改用 RoundToEven，同时测试相邻奇数与偶数候选。
• 通用函数覆盖正负零、NaN、正负无穷大。
• 保留小数位时检查缩放后的溢出和二进制近似。
• 金额或结算测试使用业务定义的十进制样例，不只测 float64。

小结：math.Round 遇到半数时远离零，是标准库公开契约：2.5 → 3，-2.5 → -3。把正负半数和相邻浮点数写进测试，就不会再靠直觉猜结果；需要半数取偶时选择 math.RoundToEven，需要精确金额语义时则应先更换数值表示，再按业务规则舍入。