Go JSON 大整数解码为何出现精度变化

Go JSON 大整数解码后尾数变化，常见原因是目标为 any 或 map[string]any，数字默认落到 float64。这会让部分大整数被舍入。改为明确的 int64 字段，或在解码前调用 Decoder.UseNumber 保留数字原文；已经丢失的位数不能靠事后转整数找回来。

官方地址：https://pkg.go.dev/encoding/json

症状指向目标类型，而非JSON文本

设想一个资料导入服务接收整数标识 9007199254740993。原始JSON可以完整写出这些数字，但二进制float64只能连续精确表示到2的53次方范围内的整数；更大的整数不是一律失真，而是不能逐个精确覆盖。这里应观察字段实际类型、原始数字文本与最终标识是否一致，而不是只看日志有没有科学计数法。

这类问题体现的是通用载荷与明确数据契约之间的取舍，并没有证据表明所有系统都在迁移到某一种写法。灵活的映射适合未知字段，但整数标识不能默认继承浮点语义。

动态字段保留数字原文

对于字段不固定的导入载荷，UseNumber让接口值中的数字保存为 json.Number。它保留文本，尚未决定业务允许的整数范围。以下是原创示例，供读者在自己的环境复现，没有附带实测输出。

package main

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

func main() {
    // 在Decode之前启用Number，避免接口数字先转为float64。
    dec := json.NewDecoder(strings.NewReader(`{"record_id":9007199254740993}`))
    dec.UseNumber()
    var payload map[string]any
    if err := dec.Decode(&payload); err != nil {
        fmt.Println("JSON解析失败:", err)
        return
    }
    // 类型断言同时处理字段缺失、null和非数字的情况。
    number, ok := payload["record_id"].(json.Number)
    if !ok {
        fmt.Println("record_id必须是数字")
        return
    }
    id, err := number.Int64()
    if err != nil {
        fmt.Println("record_id不是可接收的int64整数:", err)
        return
    }
    fmt.Println("整数标识:", id)
}

判断标准是错误分支得到处理、Number文本仍与输入数字一致，以及业务接收的整数范围明确。UseNumber不修复上游已经舍入的数据，也不会让后续 Float64() 自动拥有任意精度。小数和指数写法即使代表整数数学值，也不能假设 Int64() 会按业务期望接受；应明确接口是否只允许十进制整数字面量。

固定字段采用明确整数契约

字段结构已知时，可以直接使用整数结构体。不要先解码到通用映射，再把float64转换成int64；那只改变类型，不恢复原文。

package main

import (
    "encoding/json"
    "fmt"
)

func main() {
    // 固定整数类型直接承接JSON数字，避免浮点数中转。
    var record struct {
        ID int64 `json:"record_id"`
    }
    data := []byte(`{"record_id":9007199254740993}`)
    if err := json.Unmarshal(data, &record); err != nil {
        // 超范围或不匹配的数字必须拒绝，不能继续消费部分数据。
        fmt.Println("记录无效:", err)
        return
    }
    fmt.Println("整数标识:", record.ID)
}

int64提供的是有符号64位整数范围，既不是任意长度整数，也不是字段必填校验。缺失字段与零值是否允许，需要业务另外规定。仅仅改成平台相关的int，也不能视为稳定的跨环境契约。

跨服务采用与观察指标

字符串标识可避免接收端主动把它当数字，但不能恢复生产者已经丢失的精度。Go中的 json:",string" 是具体字段的编码约定，应与普通string字段区分；更改线上数字字段为字符串也可能破坏旧消费者，不能仅靠服务端单侧改动。

落地时先标记承担标识语义的字段，再确定接收类型和允许范围，随后与调用方协调字段契约。观察整数解析失败数量、字段类型不匹配数量、原始文本与存储值不一致的样本，以及仍在依赖旧数字类型的消费者。这些是建议观察项，本文不声称已有线上统计或性能收益。

UseNumber会影响结构体中的float64字段吗？

它针对解码到接口值时的数字选择，不会把明确声明的float64字段变成任意精度数字。

输出成科学计数法就是丢精度吗？

不是。显示格式与数值是否能精确表示应分别判断；比较原始数字、实际类型和业务允许范围更有意义。

超过int64范围怎么办？

只作标识可协商字符串；需要整数运算时可以保留Number原文，再使用math/big.Int解析。不能忽略Int64返回的错误。

参考：Go JSON数字解码文档、Go大整数文本解析文档。