在 Go 里执行 fmt.Println(0.1 + 0.2)，控制台输出的不是 0.3，而是 0.30000000000000004。这个结果常常让初学者感到困惑，甚至怀疑语言本身出了问题。实际上，这是所有遵循 IEEE 754 标准的编程语言都会遇到的现象，Go 的 float64 和 float32 类型在底层都用二进制近似表示十进制小数，而大部分十进制小数无法被二进制精确表示。想要控制计算结果，就需要理解误差来源，并熟练使用 math 包等工具做收敛处理。
浮点精度偏差的根源：IEEE 754 与二进制近似
Go 语言中的 float64 类型对应 IEEE 754 双精度浮点数，它使用 64 位存储，其中 1 位符号位、11 位指数位、52 位尾数位。这种设计可以让数值在极大范围内分布，但代价是很多十进制小数无法精确表示。例如 0.1 转成二进制后是 0.00011001100110011001100110011...，这是一个无限循环小数，存储时只能截取前 52 位尾数，多出来的部分就被舍入，于是产生了一个非常接近但不等于 0.1 的近似值。
当两个近似值相加时，舍入误差会继续传播。0.1 的近似值加上 0.2 的近似值，得到的是 0.30000000000000004，而不是精确的 0.3。类似的情况还有 1.1 减去 1.0 得到 0.10000000000000009，2.675 乘以 100 得到 267.49999999999997。这些误差不是 Go 特有的，Java、JavaScript、Python 中的双精度浮点数都会出现同样问题，只是 Go 在格式化输出时默认展示了更多有效位，让误差更明显。
理解这一点后，开发者不应该再用 == 直接比较两个浮点数是否相等，而应该通过计算差值的绝对值是否小于一个极小量来判断。这个极小量通常称为 epsilon，比如 1e-9。对于需要精确小数位的业务场景，则需要借助 math 包或其他高精度计算方案对结果做控制。
math 包核心函数：截断、取整与四舍五入
Go 标准库的 math 包提供了一组对浮点数取整和舍入的函数，它们的作用各不相同，适合不同业务需求。math.Floor 返回不大于参数的最大整数，也就是向下取整；math.Ceil 返回不小于参数的最小整数，也就是向上取整；math.Trunc 直接丢弃小数部分，向零取整；math.Round 则按照四舍五入规则返回最接近的整数，当小数部分恰好为 0.5 时，它会远离零取整；math.RoundToEven 使用银行家舍入法，将中间值舍入到最接近的偶数，适合减少统计上的累计偏差。
下面这段代码展示了这些函数的执行结果：
package main
import (
"fmt"
"math"
)
func main() {
x := 2.7
y := -2.7
fmt.Println(math.Floor(x)) // 2
fmt.Println(math.Ceil(x)) // 3
fmt.Println(math.Trunc(x)) // 2
fmt.Println(math.Round(x)) // 3
fmt.Println(math.Floor(y)) // -3
fmt.Println(math.Ceil(y)) // -2
fmt.Println(math.Trunc(y)) // -2
fmt.Println(math.Round(y)) // -3
fmt.Println(math.RoundToEven(2.5)) // 2
fmt.Println(math.RoundToEven(3.5)) // 4
}
可以看到，正数和负数场景下，Floor 和 Trunc 的行为并不相同：Floor 始终向负无穷方向移动，而 Trunc 只是简单地去掉小数部分。很多开发者在处理负数金额时容易混淆这两个函数，导致计算结果偏向错误方向。建议在涉及退款、扣减等负值场景时，先明确业务上希望向零收敛还是向负无穷收敛，再选择对应函数。
这些函数返回的都是 float64 类型而不是整数类型，因此后续计算仍然以浮点数形式进行。对于小数位控制，单靠这些函数还不够，需要结合乘除运算来实现保留指定位数的小数。
用 math 包控制小数位数：先乘后除方案
保留两位小数是常见需求，最直观的做法是先把原数乘以 100，调用 math.Round 取整后再除以 100。例如将 3.14159 保留两位小数，可以写 math.Round(3.14159*100) / 100，得到 3.14。这种方法在大多数数据范围内是有效的，代码简洁，执行速度快，适合对实时性要求较高的统计场景。
package main
import (
"fmt"
"math"
)
func roundToDecimal(x float64, places int) float64 {
factor := math.Pow(10, float64(places))
return math.Round(x*factor) / factor
}
func main() {
fmt.Println(roundToDecimal(3.14159, 2)) // 3.14
fmt.Println(roundToDecimal(2.675, 2)) // 2.68，可能不符合预期
fmt.Println(roundToDecimal(0.1+0.2, 2)) // 0.3
}
不过，先乘后除并非万能。由于浮点数乘法本身可能产生新的舍入误差，某些临界值会出现不符合预期的结果。典型例子是 2.675 保留两位小数，数学上四舍五入应为 2.68，但实际代码返回 2.67。原因是 2.675 在二进制中实际存储为 2.6749999999999998，乘以 100 后得到 267.49999999999997，math.Round 距离 267 更近，于是结果偏小。要缓解这种问题，可以在乘法后加上一个极小的 epsilon 修正，比如 math.Round(x*factor + 1e-9) / factor，但 epsilon 的选择与数值范围相关，并不能覆盖所有边界情况。
因此，当业务对小数精度要求不高，比如用于展示统计平均值、生成报表数据时，先乘后除配合 math.Round 是足够的。但如果涉及金额计算、库存扣减、财务对账等场景，这种方案的风险就会暴露，需要引入 big.Float 或者专门的 decimal 库来保证精度。
替代方案：big.Float 与 decimal 库的适用边界
Go 标准库中的 math/big 包提供了任意精度的浮点数类型 big.Float，它不像 float64 那样固定 64 位存储，而是可以根据需要动态扩展精度。通过 big.NewFloat 创建高精度数值，再使用 SetPrec 设置有效位，SetMode 指定舍入模式，可以显著降低计算过程中的累计误差。下面示例计算 0.1 加 0.2 并保留 30 位精度：
package main
import (
"fmt"
"math/big"
)
func main() {
a := new(big.Float).SetPrec(128).SetFloat64(0.1)
b := new(big.Float).SetPrec(128).SetFloat64(0.2)
sum := new(big.Float).Add(a, b)
fmt.Println(sum.Text('f', 30)) // 0.3 后面补零
}
big.Float 虽然精度高，但 API 相对繁琐，性能也比原生 float64 差很多，适合对精度要求极高但计算量不大的场景。如果项目中大量使用货币计算，更推荐使用经过验证的第三方 decimal 库，例如 shopspring/decimal，它内部用整数表示小数，从根本上避免二进制浮点误差，同时提供了丰富的四则运算、舍入和格式化方法。使用前需要通过 go get 安装依赖，并在代码中导入相应包。
在实际选型时，可以按照以下原则判断：如果只是展示层需要固定小数位，使用 fmt.Sprintf 格式化字符串最直接；如果需要参与后续浮点运算且对性能敏感，可以用 math 包先乘后除；如果涉及货币、金融、会计等不能容忍误差的领域，必须使用 big.Float 或 decimal 库。无论选择哪种方案，都应该在单元测试中覆盖边界值，比如 2.675、0.1+0.2、负数舍入等，避免上线后才发现隐性偏差。
浮点数精度问题在 Go 中只能被控制，不会被彻底消除。理解 IEEE 754 的存储限制，掌握 math 包各个取整函数的差异，并能在合适场景引入高精度计算方案，是写出健壮数值处理代码的关键。
Golang浮点数精度math包四舍五入修改时间：2026-10-02 01:35:59