json.Unmarshal 为什么会把大整数变成浮点数，怎样保留精度

把 JSON 解码到明确的 Go 结构体时，大整数可以直接进入 int64 等目标字段；真正容易出问题的是 json.Unmarshal 把对象放进 interface{}、map[string]any 后，按照默认规则把 JSON number 存成 float64。浮点数一旦在解析阶段丢掉低位，后面再转回整数也救不回来。

边界明确的 ID、计数和时间戳优先定义为 int64 字段；必须接收动态 JSON 时，用 json.Decoder.UseNumber() 保留数字字面量，再显式调用 Int64() 或 String() 并检查错误。

先把精度风险定位到目标类型

问题通常出现在“先收成通用对象，后面再猜字段”的代码里。encoding/json 文档明确规定：解码到 interface 值时，JSON number 对应 float64，对象则会形成 map[string]any。所以像订单号 9007199254740993 这类超过浮点数安全整数范围的值，不应先进入通用对象。

边界明确时，直接定义请求结构体，把解析和范围检查交给目标类型：

package main

import (
    "encoding/json"
    "fmt"
)

type Request struct {
    // ID 代表不可分割的整数标识，避免先落入 float64。
    OrderID int64 `json:"order_id"`
}

func main() {
    var req Request
    // 解析失败或超出 int64 范围时必须停止处理。
    if err := json.Unmarshal([]byte(`{"order_id":9007199254740993}`), &req); err != nil {
        fmt.Println("拒绝请求:", err)
        return
    }
    fmt.Println(req.OrderID)
}

这条路径的安全收益是类型边界清楚：越界会返回 UnmarshalTypeError，调用方可以拒绝请求。不要把 map[string]any 中已经变形的值再格式化成字符串，那个动作只是在掩盖损失。

动态 JSON 的两条保精度路径

有些网关需要兼容多个版本的字段，确实不能马上落到固定结构体。这时使用 Decoder 而不是直接把字节交给 Unmarshal，并在第一次读取前调用 UseNumber：

package main

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

func readOrderID(data []byte) (int64, error) {
    dec := json.NewDecoder(bytes.NewReader(data))
    // 让动态对象中的数字保留为 json.Number，而不是 float64。
    dec.UseNumber()

    var payload map[string]any
    if err := dec.Decode(&payload); err != nil {
        return 0, fmt.Errorf("解码 JSON: %w", err)
    }
    raw, ok := payload["order_id"].(json.Number)
    if !ok {
        return 0, fmt.Errorf("order_id 不是 JSON number")
    }
    // Int64 会拒绝小数和超出 int64 的字面量。
    id, err := raw.Int64()
    if err != nil {
        return 0, fmt.Errorf("order_id 无法作为 int64: %w", err)
    }
    return id, nil
}

UseNumber 只负责保存原始数字文本，不替你决定业务类型。计量值可能需要 Float64()，编号通常应走 Int64()，而不能用一个“统一转浮点”的辅助函数。要保留任意长数字或原样回传时，直接使用 raw.String()，并配合长度、字符集和格式检查。

把跨语言 ID 的格式写进数据契约

如果 JavaScript、浏览器或第三方服务把 ID 当作字符串发送，Go 端就应把它当作字符串边界处理，而不是为了方便再转成 float64。这种设计牺牲了“看起来像数字”的便利，却保住了标识符的逐字符一致性。

尤其要注意“成功解码”不等于“业务输入可信”：解析后仍应检查 ID 是否为正数、是否属于当前租户、是否能在数据库中找到对应资源。精度控制解决的是身份一致性，权限控制解决的是能不能访问，两者不能互相替代。

常见问题

直接把 float64 转成 int64 能修复吗？

不能保证。若低位已经在浮点转换时丢失，转换只会得到一个错误但看似合法的整数。必须在第一次解码前改成强类型或 UseNumber。

所有数字都应该使用 json.Number 吗？

不必。固定结构的字段用明确的 int64、uint64 或 float64 更清晰；只有结构动态、需要延后决策或要保留原文字面量时才使用 json.Number。

怎么快速复查一段动态 JSON 代码？

沿着“输入 → 第一次解码 → 中间类型 → 转换 → 业务校验”检查：只要第一次解码目标是 interface{} 且没有 UseNumber，就应优先排查大整数是否已经经过 float64。