Go语言处理大整数精度问题实战

Go语言在JSON解析中处理大整数（尤其是int64）时存在严重精度丢失问题，根源在于默认将数字转为float64，而其53位有效精度无法准确表示超过2^53的整数值，导致分布式ID、大金额等关键场景出现隐性错误；本文直击痛点，详解两种高可靠性解决方案——轻量灵活的json.Number拦截+手动Int64转换，以及可复用、可校验的自定义SafeInt64类型实现，同时明确指出UseNumber()的全局副作用陷阱，帮你避开线上事故雷区。

Go JSON 解析 int64 时精度丢失的根源

Go 的 json.Unmarshal 默认把 JSON 数字当 float64 解，哪怕原始值是 9223372036854775807 这种合法 int64 最大值，也会先转成 float64 再强转——而 float64 只有 53 位有效精度，超过 2^53（约 9007199254740992）的整数就会丢低比特位。

常见错误现象：
前端传 {"id": 9223372036854775806}，后端解析出 9223372036854775808 或 9223372036854775800；fmt.Printf("%d", v) 看似正常，但做等值比较或数据库写入时出错。

用 json.Number 拦截原始字符串再手动转 int64

这是最轻量、兼容性最好的方案：不改结构体定义，只在解码时接管数字处理逻辑。

• 定义结构体字段为 json.Number 类型（本质是 string），避免自动 float 转换
• 解码后调用 .Int64() 方法——它内部用 strconv.ParseInt，能精确处理 64 位整数
• 注意：如果 JSON 数字带小数点（如 123.0），json.Number.Int64() 会直接报错 invalid syntax，需提前判断或容错

var data struct {
    ID json.Number `json:"id"`
}
if err := json.Unmarshal(b, &data); err != nil {
    // ...
}
id, err := data.ID.Int64() // 精确转换

自定义类型 + UnmarshalJSON 方法（适合高频复用场景）

当你有多个字段都要走 int64 精确解析，或者想统一处理溢出/非法格式时，封装一个类型更可控。

• 定义新类型如 type SafeInt64 int64，实现 UnmarshalJSON([]byte) error
• 方法体内用 strconv.ParseInt(string(b), 10, 64)，比 json.Number.Int64() 多一层对引号包裹数字（如 "123"）的兼容
• 务必检查 err == nil，且结果在 [math.MinInt64, math.MaxInt64] 范围内——JSON 允许超范围数字，但 Go 不接受

func (s *SafeInt64) UnmarshalJSON(b []byte) error {
    s64, err := strconv.ParseInt(strings.Trim(string(b), `"`), 10, 64)
    if err != nil {
        return err
    }
    *s = SafeInt64(s64)
    return nil
}

别碰 UseNumber() —— 它只是开关，不是银弹

json.Decoder.UseNumber() 确实能让所有数字字段变成 json.Number，但它影响全局行为，容易引发隐性问题：

• 后续代码若没显式调用 .Int64()，而是直接赋值给 int64 变量，会触发隐式转换，又回到 float64 陷阱
• 和第三方库（比如 gorilla/schema 或某些 ORM）配合时，可能因期望 float64 类型而 panic
• 无法区分哪些字段需要高精度、哪些可以容忍 float（比如时间戳毫秒值通常没问题，但分布式 ID 绝对不行）

真正要的是按字段控制，不是全局切换。该用 json.Number 字段就用，该封装类型就封装。

最容易被忽略的一点：前端传来的数字是否真的总是整数？如果 API 文档没强制约定，就得在 UnmarshalJSON 里加小数点检测，或者接受 float64 后做 math.Floor 校验——但后者本身就有精度风险。

今天关于《Go语言处理大整数精度问题实战》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！