Go JSON 数字进 interface 后为什么变成 float64

排查动态 JSON 时，经常会看到一个看似奇怪的结果：输入里的 123 没有变成 Go 的 int，放进 interface{} 后却是 float64。这是 encoding/json 对未知 JSON 数字的默认表示，并不是 JSON 文本被自动改成了小数。

如果字段结构确定，优先解码到具体的整数类型；如果必须接收动态对象，就先调用 Decoder.UseNumber()，让数字以 json.Number 保留文本，再按业务需要转成 Int64 或字符串。

Go JSON 数字进 interface 后为什么会变成 float64

先看最小现场。对象没有对应的结构体，解码目标只能写成 map[string]any：

package main

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

func main() {
    var payload map[string]any
    // 动态对象没有具体字段类型，标准库按默认规则落地数字。
    err := json.NewDecoder(strings.NewReader(`{"id": 123}`)).Decode(&payload)
    if err != nil {
        panic(err)
    }
    // 这里的断言会失败，因为 id 的动态类型是 float64。
    fmt.Printf("%T %v\n", payload["id"], payload["id"])
}

当目标是 interface{} 或 any，标准库需要在运行时为 JSON 的对象、数组、字符串、布尔值、数字和 null 选择一组 Go 表示。数字的默认表示就是 float64，所以 payload["id"].(int64) 不是正确的读取方式。若目标是结构体字段 int64，则会按字段的静态类型解码，两者不要混为一谈。

大整数为什么不能直接依赖 float64

float64 适合表达带小数的计算值，却不是保存任意长整数文本的容器。JavaScript 风格的 JSON 数字在跨系统传输时，业务常把长整型 ID 放在数字位置；一旦动态解码先落成浮点数，后面再转整数或重新编码，就可能得到与原文不同的值。

这里要区分三个问题：数值能否被解析、解析后是否仍精确、业务是否允许小数。json.Number 本质上保存 JSON 数字字面量的文本；调用 Int64() 时，超出 int64 范围或带小数都会返回错误，调用 String() 则可继续把它交给 decimal 库或作为外部标识保存。

不要用 fmt.Sprint 把已经变成 float64 的值“还原”为原始数字。那只能格式化当前浮点值，无法找回可能已经丢失的数字位。

用 Decoder.UseNumber 保留 JSON 数字文本

动态字段必须保留时，把开关放在真正执行 Decode 之前：

package main

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

func main() {
    var payload map[string]any
    dec := json.NewDecoder(strings.NewReader(`{"id": 9223372036854775807, "ratio": 1.25}`))
    // 让接口值中的数字保留为 json.Number，而不是先转成 float64。
    dec.UseNumber()
    if err := dec.Decode(&payload); err != nil {
        panic(err)
    }

    id, ok := payload["id"].(json.Number)
    if !ok {
        panic("id 不是 json.Number")
    }
    // Int64 会做范围和格式检查；失败时不能静默使用零值。
    value, err := id.Int64()
    if err != nil {
        panic(err)
    }
    fmt.Printf("%T %d\n", id, value)
}

此时 id 和 ratio 都是 json.Number。前者可以调用 Int64()，后者不应强行调用 Int64()，应依据业务选择 Float64() 或保留 String()。实际服务里把示例中的 panic 换成带字段名的错误返回，并记录请求上下文。

结构体、UseNumber 与 string 字段怎么选

最后做三项复查：第一，确认 UseNumber 出现在 Decode 之前；第二，不把 json.Number 当成已经验证过的业务数字；第三，检查下游序列化、日志和数据库字段是否仍会把它转换成浮点数。这样才能真正守住精度边界。

常见问题

为什么把 map 改成 map[string]int64 就正常了？

因为目标类型已经明确，解码器不需要为数字选择 interface 的默认表示；但输入不合法或超出范围时仍应检查 Decode 返回的错误。

UseNumber 会让所有 JSON 数字都变成整数吗？

不会。它只把接口值中的数字保存为 json.Number；整数、小数和范围判断仍由后续调用的方法决定。

已经拿到 float64，还能恢复长整数原文吗？

通常不能可靠恢复。应从解码入口改用具体类型或 UseNumber，并为旧数据准备重新获取原始 JSON 的路径。