Go JSON 数字转 interface 后精度丢失怎么保留

Go 用 encoding/json 把 JSON 解码到 interface{} 时，未知数字默认会落成 float64。小数和普通计数通常看不出问题，但订单号、雪花 ID 或超过安全整数范围的值一旦经过浮点数，可能在后续断言、再编码时失真。修复重点不是“把 float64 再转回 int64”，而是让数字在进入动态容器时就保留正确的表示。

动态 JSON 用 Decoder.UseNumber() 保留数字词法；需要按类型延迟判断时用 json.RawMessage；字段契约已经确定时，直接在结构体中使用 int64、uint64 或字符串。

一、先定位精度丢失发生在哪一层

下面这段写法很常见：把响应解码到 map[string]interface{}，再从 map 中取出数字。问题在于，目标类型没有告诉解码器这个数字应该是整数还是小数，于是标准库选择了通用的 float64。

var payload map[string]interface{}
if err := json.Unmarshal(data, &payload); err != nil {
    // 输入不是合法 JSON 时，先返回解析错误。
    return err
}

// 这里的 v 通常是 float64，而不是原始 JSON 数字类型。
v, ok := payload["order_id"].(float64)
if !ok {
    return errors.New("order_id 不是预期的数字")
}
fmt.Println(v)

因此，先不要用 int64(v) 掩盖问题。若数字已经在浮点表示中发生舍入，转换只是在错误结果上换了一个整数类型。

二、用 UseNumber 保留数字词法

当字段集合不固定、又不能马上为每个字段建结构体时，改用 Decoder 并调用 UseNumber。它会让动态值里的数字以 json.Number 保存，而不是自动变成 float64。

decoder := json.NewDecoder(bytes.NewReader(data))
decoder.UseNumber() // 让 interface{} 中的数字保留为 json.Number

var payload map[string]interface{}
if err := decoder.Decode(&payload); err != nil {
    // Decode 失败时不要继续读取动态字段。
    return err
}

number, ok := payload["order_id"].(json.Number)
if !ok {
    return errors.New("order_id 不是 json.Number")
}
orderID, err := number.Int64()
if err != nil {
    // 超出 int64 或带小数时，在这里显式暴露边界。
    return fmt.Errorf("order_id 不能按 int64 读取: %w", err)
}
fmt.Println(orderID)

json.Number 的价值是延后决定：计数可以调用 Int64，确实需要浮点计算时再调用 Float64，只是后者仍然要承担浮点精度边界。金额、编号等不可近似的数据，不要因为能转成浮点就选择 Float64。

三、用 RawMessage 延迟解析多态字段

如果对象的真实结构由 kind、type 等字段决定，与其把整棵树塞进 interface{}，不如只把变化部分声明为 json.RawMessage。它保留一段原始 JSON，等待判定类型后再解码。

type Envelope struct {
    Kind string          `json:"kind"`
    Data json.RawMessage `json:"data"` // 延迟解析变化字段
}

var envelope Envelope
if err := json.Unmarshal(data, &envelope); err != nil {
    // 外层协议错误应在判断 kind 前返回。
    return err
}

switch envelope.Kind {
case "invoice":
    var invoice struct {
        ID     int64  `json:"id"`
        Amount string `json:"amount"`
    }
    if err := json.Unmarshal(envelope.Data, &invoice); err != nil {
        return err
    }
    fmt.Println(invoice.ID, invoice.Amount)
default:
    return fmt.Errorf("不支持的 kind: %s", envelope.Kind)
}

这里的 ID 和 Amount 已经回到业务结构中，编号不会先绕道 float64。金额示例使用字符串，是因为金额通常需要十进制定点语义；如果上游契约明确是整数分，也可以改成 int64 并在边界处检查。

四、按数据契约选择最终类型

可以按下面的判断表收敛方案：

最后检查三件事：数字是否经过 interface{}，是否有大于目标整数范围的输入，是否在重新编码前被转成了浮点。只要数据契约已知，明确结构体字段通常比动态 map 更安全，也更容易让错误在解码时暴露。

常见问题

已经拿到 float64，还能可靠恢复原始大整数吗？

不能保证。若浮点表示已经舍入，后续转换无法找回丢失的低位。应回到原始 JSON，用 UseNumber、RawMessage 或字符串字段重新解码。

UseNumber 会自动把数字变成 int64 吗？

不会。它返回 json.Number，由调用方选择 Int64 或 Float64，并自行处理转换错误。

所有 JSON 数字都应该用字符串吗？

不应该。需要计算且范围明确的计数可以使用整数；只有跨系统编号、超大整数或必须保持文本形式的值才适合字符串。