jsonNumber被转成浮点数怎么办

如果你在 Go 里看到“jsonNumber 被转成浮点数”，先别急着把 float64 强转回整数。最常见的原因是 JSON 被解码到了 any、interface{} 或 map[string]any：encoding/json 对这类动态目标的默认规则就是把 JSON 数字放进 float64。需要保留数字文本时，应在 Decode 之前调用 Decoder.UseNumber()；如果值已经变成了 float64，最稳妥的办法是拿原始 JSON 重新解码。

本文只解决 json.Number、float64 与动态 JSON 解码之间的类型边界，不把浮点数改写成“看起来像整数”的结果。

先确认是谁把数字变成了 float64

下面这个现象不是 JSON 文本自己改变了，而是解码目标决定了 Go 值的类型。解码到结构体的明确字段时，字段类型由结构体声明；解码到 any 时，数字没有更具体的目标类型，标准库默认选择 float64。

package main

import (
    "encoding/json"
    "fmt"
)

func main() {
    // 动态容器没有声明数字类型，标准库会把 JSON 数字映射成 float64。
    var payload map[string]any
    data := []byte(`{"id":9007199254740993}`)
    if err := json.Unmarshal(data, &payload); err != nil {
        // 解码错误必须向上返回，不能用零值掩盖输入问题。
        panic(err)
    }
    fmt.Printf("%T %v\n", payload["id"], payload["id"])
}

相反，json.Number.Float64() 是调用方主动选择浮点解析；json.Number 本身是保存数字字面量的字符串类型，不会因为名字里有 Number 就自动变成浮点数。排查时先搜索两处：解码目标是否为 any，以及后续是否显式调用了 Float64()。

固定结构时直接声明目标类型

如果接口字段稳定，不要先解码成 map[string]any 再猜类型。整数标识可以声明为 int64，确实允许小数的字段声明为 float64，需要保留原始数字文本时则声明为 json.Number。这样类型约束会在解码边界表达出来。

type Event struct {
    // json.Number 先保留字面量，业务层再决定如何消费它。
    ID json.Number `json:"id"`
}

var event Event
if err := json.Unmarshal(data, &event); err != nil {
    // 输入不符合数字语法时，保留错误并停止继续转换。
    return err
}

id, err := event.ID.Int64()
if err != nil {
    // 小数、指数形式或超出 int64 范围时，不把失败值当成有效 ID。
    return fmt.Errorf("parse id %q: %w", event.ID.String(), err)
}
fmt.Println(id)

注意，声明成 json.Number 只解决“先保留什么”，不替你决定“最终用什么”。Int64() 适合有符号 64 位整数，Float64() 适合确实接受浮点语义的值；两者都要检查返回的错误。

动态 JSON 要在 Decode 前启用 UseNumber

字段不固定时，可以继续使用 map[string]any，但要把 UseNumber() 放在第一次 Decode 之前。这样动态对象中的数字会进入 json.Number，原始文本还在，调用方可以先用 String() 留存，再选择 Int64() 或 Float64()。

dec := json.NewDecoder(bytes.NewReader(data))
// 改变动态数字的落点，必须发生在 Decode 之前。
dec.UseNumber()

var payload map[string]any
if err := dec.Decode(&payload); err != nil {
    // 解码失败时不要继续从 payload 读取半成品。
    return err
}

n, ok := payload["id"].(json.Number)
if !ok {
    // 类型不符合预期时保留现场，方便定位上游或解码入口。
    return fmt.Errorf("id has type %T", payload["id"])
}
raw := n.String()
id, err := n.Int64()
if err != nil {
    // raw 可用于日志或转交下游，err 用于区分格式和范围问题。
    return fmt.Errorf("id %q is not int64: %w", raw, err)
}
fmt.Println(id)

如果已经先调用过 json.Unmarshal 或 Decode，再补一句 UseNumber() 不会改变已有值；它只影响后续解码。更不能把已经失真的 float64 通过格式化重新包装成 json.Number，那只是保存了浮点结果，不是恢复原始 JSON。

已经是 float64 时怎么补救

先判断手里是否还保留原始 JSON 字节。如果有，就重新创建 Decoder，先调用 UseNumber()，再解码；如果只剩一个 float64，只能承认当前值已经是浮点语义。对于订单号、用户 ID、金额分位等要求精确的字段，应把原始 JSON 或上游字符串重新送入解析边界，而不是依赖四舍五入。

可以用下面的清单快速选出口：

常见问题

json.Number 会自动避免所有精度问题吗？

不会。它只负责保留数字文本；调用 Float64() 后仍然进入浮点边界，调用 Int64() 也可能因为小数或范围不足返回错误。

UseNumber 能影响结构体里的 float64 字段吗？

不能。UseNumber 主要改变解码到接口值时的数字落点；结构体字段声明为 float64 时，字段仍按声明的类型接收。

为什么类型断言从 float64 改成 json.Number？

因为启用 UseNumber 后，动态容器中的数字类型确实变成了 json.Number。类型断言、转换错误和后续业务分支都要随解码策略一起调整。

总结一下：默认 any 解码得到 float64 是标准规则；要保留原始数字，就在 Decode 前启用 UseNumber，并把最终转换放在业务边界显式完成。已经丢成 float64 时，优先重新使用原始 JSON 解码。