Go json.Decoder.UseNumber 为什么能避免浮点精度变化

我在处理一段“字段不固定、数字又不能随便四舍五入”的 JSON 时，真正的问题不在 UseNumber 会不会提高精度，而在默认解码已经把数字变成了 float64。只要目标是 interface{}，Go 的 encoding/json 默认就会这样做；在 Decode 前调用 UseNumber()，数字会先保留为 json.Number，等业务代码决定转整数、浮点数，还是交给精确十进制方案。

Go 默认解码为何先落到 float64

JSON 只有一个 number 类型，并没有“这是 int64”或“这是金额小数”的标记。因此，当接收端是 map[string]any 或其他 interface{} 时，标准库只能采用统一的默认映射：布尔值变成 bool，字符串变成 string，数字变成 float64。

这会带来一个容易忽略的时序问题。假设 JSON 里有一个超过常见浮点精确整数范围的编号，解码器先把它交给二进制浮点表示，原始十进制文本就可能无法原样保留。后面再把这个 float64 转成整数或字符串，已经没有机会找回原始数字了。

因此，问题的判断标准不是“打印出来看起来像不像”，而是接收结构是否真的允许先经过 float64。如果字段能直接定义成 int64，让解码器按目标类型写入通常更清楚；只有在结构动态、字段类型不稳定时，才需要保留数字文本。

Go UseNumber 把数字留在 json.Number

UseNumber 要在第一次 Decode 之前调用。它改变的是“JSON number 写入 interface{} 时使用什么动态类型”，不是改变 JSON 语法，也不是把所有数字自动升级成高精度数。

package main

import (
    "encoding/json"
    "fmt"
    "strings"
)

func main() {
    input := `{"id":9007199254740993,"ratio":0.1}`
    var payload map[string]any

    dec := json.NewDecoder(strings.NewReader(input))
    dec.UseNumber() // 先保留 JSON 数字文本，避免默认落到 float64
    if err := dec.Decode(&payload); err != nil {
        panic(err) // 示例中直接终止；服务代码应返回带上下文的错误
    }

    id := payload["id"].(json.Number)
    fmt.Println(id.String()) // 这里仍可读到原始数字文本
}

默认路径中的 payload["id"] 是 float64；启用后它是 json.Number。后者底层仍然是数字文本，String() 适合记录或继续交给业务解析。这个变化把“先猜类型”的责任交还给调用方，也让错误发生在更明确的边界。

按业务类型显式完成二次解析

拿到 json.Number 后不要长期把它当作万能字符串。先判断字段的业务含义，再选择转换方法：整数编号用 Int64()，允许近似计算的测量值用 Float64()，要求十进制规则稳定的金额或比例则保留文本并交给项目选定的十进制实现。

func readAmount(payload map[string]any) (int64, error) {
    raw, ok := payload["amount"].(json.Number)
    if !ok {
        return 0, fmt.Errorf("amount 不是 json.Number") // 先检查动态类型
    }

    amount, err := raw.Int64()
    if err != nil {
        return 0, fmt.Errorf("amount 不是可表示的整数: %w", err) // 拒绝小数或溢出
    }
    return amount, nil
}

若输入是 12.50，调用 Int64() 会失败，这反而是有价值的信号：字段边界与代码假设不一致。调用 Float64() 也要检查错误，因为它可能遇到无法表示或超出范围的输入。对于金额，UseNumber 只能保住文本，不能替你完成精确加减、舍入和币种规则。

哪些场景不需要 UseNumber

如果接口结构稳定，使用结构体比先解到 map[string]any 更容易维护。比如 type Event struct { Count int64 `json:"count"` } 已经表达了字段契约，不需要为了避免默认 float64 再套一层 UseNumber。

还要注意，UseNumber 只影响解码到 interface 的数字；它不会改变字符串形式的数字，也不会自动验证业务范围。对外部输入仍应检查字段是否存在、是否允许负数、是否超出数据库列或领域模型的边界。把这几步写在转换处，排查时比在后面追一个“数值怎么变了”的结果更省时间。

常见问题：UseNumber 的几个边界

UseNumber 会让 JSON 数字变成字符串吗？

不会。它会让解码到 interface{} 的数字使用 json.Number，这是标准库提供的数字类型；只有调用 String() 时才读取它的文本表示。

调用 UseNumber 后就能保证金额精确吗？

不能。它避免了先经过 float64，但金额的精确运算、舍入和格式化仍需要明确的十进制策略。

为什么我的结构体字段不受这个问题影响？

结构体字段已有目标类型，解码器会按字段类型处理。这个问题主要出现在动态接收 JSON、再由业务代码猜测数字含义的场景。