Go JSON Decoder 怎样保留大整数精度

Go JSON Decoder 保留大整数精度的最小写法，是在 Decode 之前对同一个解码器调用 UseNumber，再把动态容器里的数字作为 json.Number 处理。不要先解析成 float64 再转 int64；已经被舍入的低位无法通过类型转换补回来。本文只讨论 import "encoding/json" 的 Decoder、UseNumber 与后续转换。

官方文档：https://pkg.go.dev/encoding/json

先用最小写法保住数字文本

package main

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

func main() {
    // 数字不带引号，刻意使用超过连续精确整数区间的值。
    input := `{"id":9007199254740993}`
    dec := json.NewDecoder(strings.NewReader(input))
    dec.UseNumber() // 必须在 Decode 之前设置当前解码器。
    var obj map[string]interface{}
    if err := dec.Decode(&obj); err != nil {
        fmt.Println("JSON解析失败:", err)
        return
    }
    n, ok := obj["id"].(json.Number)
    if !ok { // 缺字段、null或字符串都不能直接当作数字。
        fmt.Println("id不是JSON数字")
        return
    }
    id, err := n.Int64() // 检查整数语法及int64范围，不经过浮点数。
    if err != nil {
        fmt.Println("id无法转为int64:", err)
        return
    }
    fmt.Println(n.String(), id)
}

示例中的 id 是 JSON 数字，不是字符串。按这段代码的语义，n.String() 与整数展示应均为 9007199254740993；这是供读者复现的预期，不是本机运行记录。遇到解析错误、字段缺失或转换错误应停止使用该值，而不是继续拿零值查询数据。

低位改变，先检查数字进了什么类型

解码到 interface{} 时，encoding/json 默认用 float64 表示 JSON 数字；map[string]interface{} 和嵌套动态数组也会遇到这一规则。float64 可以精确表示许多整数，但超过 2 的53次方后，不再能连续精确表示每一个整数。9007199254740993 就是适合暴露低位问题的例子。显示成科学计数法本身不等于丢精度，关键是内部数值是否已被舍入。

UseNumber 改变的是动态接口中的数字表示：用 json.Number 保存数字字面量。它不是全局设置，也不能修复上游在浏览器、其他服务或旧解码器中已经发生的舍入。先看原始响应文本，再看接收类型，最后看后续转换，才能区分输入已经错误与本地处理错误。

保留文本之后，转换仍然可能失败

json.Number.String() 给出数字字面量文本；Int64() 用于有符号64位整数转换，必须检查返回的 error。Float64() 又会进入浮点表示，即使没有错误，大整数仍可能发生舍入。不要把“Float64 没报错”当成“整数精度没有损失”。

例如 9223372036854775808 超过 int64 上限，不能因为 UseNumber 保住了文本就继续调用 Int64 并忽略错误。1.0 和 1e3 是合法 JSON 数字，但不是 Int64 所要求的十进制整数字面量写法；数学上等于整数不代表解析语法相同。是否允许指数形式要由业务另行定义，不能先经 float64 再强转掩盖差异。

超过 int64 时，直接从文本构造大整数

大整数文档：https://pkg.go.dev/math/big

// 本片段放在取得json.Number变量n之后；文件需导入math/big。
// 只接受十进制整数字面量，不把小数或指数形式当作整数语法。
value, ok := new(big.Int).SetString(n.String(), 10)
if !ok {
    return fmt.Errorf("需要十进制整数字面量: %q", n.String())
}
fmt.Println(value.String()) // 使用十进制文本展示，不转回float64。

这是返回 error 的业务函数内片段，不是另一份 main 程序；所在文件还需已有 encoding/json 与 fmt 导入。明确指定十进制，避免把进制前缀当成接口协议。SetString 要求整个字符串可解析；成功后使用 big.Int 的方法或保留十进制文本，不要为了适配旧代码又转回 float64。对外部输入还应限制数字长度与请求体大小，任意精度不代表任意成本。

用边界用例反向核对处理链

读者复现时，可以分别输入 9007199254740993、9223372036854775808、1.0、1e3、null 和带引号的数字。第一项用于观察原始文本是否保留；第二项应保留文本但拒绝 Int64 转换；小数与指数形式用于确认整数语法策略；null 与字符串用于确认类型分支没有混淆。不要把这些预期写成所有转换都应该成功。

• UseNumber 是否调用在实际 Decode 使用的同一个 Decoder 上，并且早于 Decode？
• 是否还有代码走 json.Unmarshal 到动态接口，而未走这个 Decoder？
• 是否处理了 json.Number 类型断言失败与转换错误？
• 下游是否又调用 Float64、按浮点保存或用窄整数承接？
• 原始 JSON 是否已经被上游舍入？如果是，应修复来源，不能只改接收端。

常见问题

字段本来就是 int64，还需要 UseNumber 吗？

已知结构的 int64 字段不经过动态接口默认的 float64 表示，UseNumber 不是它的精度开关；仍应检查解码错误和范围。不要把动态 map 的问题套到所有字段。

带引号的大整数会变成 json.Number 吗？

在本例动态容器中，它是 string。UseNumber 针对 JSON 数字，不会自动把字符串变成数字。协议使用字符串时应明确解析字符串并检查格式。

重新设置 UseNumber 能恢复之前丢掉的低位吗？

不能。需要从未舍入的原始 JSON 重新解码。只把已有 float64 包装成文本，并不是恢复原始数字。

解决这类问题的关键是把“保留数字字面量”与“选择计算类型”分开：入口使用 UseNumber，出口按范围与语法选择整数转换，全程避免不必要的浮点中转。