Go JSON 序列化大整数丢失精度分析

在 Go 项目中,我们经常使用 map[string]interface{} 来表示动态字段,或者用 JSON 序列化对象存入数据库、发送到 MQ。然而,当存储或传输 大整数(int64) 时,往往会出现精度丢失的问题。本文通过一个示例来详细分析原因,并给出解决方案。


1️⃣ 场景示例

假设我们有一个动态 Extra 字段,用于存储一些扩展信息,其中 oldTask 是一个 int64 大整数:

go 复制代码
package main

import (
	"encoding/json"
	"fmt"
)

func main() {
	// 模拟 Extra 字段
	extra := make(map[string]interface{})
	extra["oldTask"] = int64(7587721483007868979)

	fmt.Println("【1】原始写入 int64:")
	fmt.Printf("type=%T, value=%v\n\n", extra["oldTask"], extra["oldTask"])
}

输出:

go 复制代码
【1】原始写入 int64:
type=int64, value=7587721483007868979

✅ 在 Go 内存中,extra["oldTask"] 正确保存了 int64 值。


2️⃣ JSON 序列化

接下来我们将这个 map 序列化为 JSON 字符串(就像你在 BuildRiskPointsStrategy 中做的):

css 复制代码
bytes, _ := json.Marshal(extra)
fmt.Println("【2】json.Marshal 后:")
fmt.Println(string(bytes), "\n")

输出:

json 复制代码
【2】json.Marshal 后:
{"oldTask":7587721483007868979}

✅ Go 的 json.Marshal 对 int64 的处理是安全的,大整数不会丢失精度。


3️⃣ JSON 反序列化到 map[string]interface{}

然而问题出现了,当我们反序列化 JSON 到 map[string]interface{} 时:

go 复制代码
var extra2 map[string]interface{}
_ = json.Unmarshal(bytes, &extra2)

fmt.Println("【3】json.Unmarshal 后:")
fmt.Printf("type=%T, value=%v\n\n", extra2["oldTask"], extra2["oldTask"])

输出:

go 复制代码
【3】json.Unmarshal 后:
type=float64, value=7587721483007869000

❌ 注意:

  • 反序列化后,extra2["oldTask"] 变成了 float64
  • 原始的 int64 值 7587721483007868979 精度丢失
  • 这是 Go 标准库 encoding/json 的默认行为:map[string]interface{} 中的数字全部解析成 float64

4️⃣ 再转回 int64

如果我们强行把它转回 int64:

css 复制代码
lost := int64(extra2["oldTask"].(float64))
fmt.Println("【4】float64 → int64 后:")
fmt.Println("value =", lost)

输出:

go 复制代码
【4】float64 → int64 后:
value = 7587721483007869000
  • 可以看到,数字已经不再精确,丢失了最后几位。

5️⃣ 对比差值

go 复制代码
fmt.Println("【5】对比:")
fmt.Println("是否相等:", lost == int64(7587721483007868979))
fmt.Println("差值:", lost-int64(7587721483007868979))

输出:

arduino 复制代码
【5】对比:
是否相等: false
差值: 79
  • 原始值与反序列化后值不一致
  • 这就是"精度丢失"的根本原因

6️⃣ 问题分析

原因总结

  1. Go 的 encoding/jsonmap[string]interface{} 反序列化时:

    • 所有数字默认是 float64
    • float64 最大安全整数范围是 -2^53 ~ 2^53
  2. 当 int64 值超出 2^53 时,float64 表示不精确 → 精度丢失

Go 官方文档说明:JSON numbers without decimal points are decoded as float64 when the target is interface{}


7️⃣ 解决方案

方案 1:使用字符串存储大整数

less 复制代码
extra["oldTask"] = fmt.Sprintf("%d", oldTaskInt64)
  • JSON 序列化后:"oldTask":"7587721483007868979"
  • 写入数据库 / MQ / ES 时不会丢精度
  • 读取时再用 strconv.ParseInt 转回 int64

方案 2:使用 json.Number 解析

css 复制代码
var extra2 map[string]interface{}
decoder := json.NewDecoder(bytes.NewReader(jsonBytes))
decoder.UseNumber() // 使用 json.Number 代替 float64
decoder.Decode(&extra2)
  • extra2["oldTask"] 类型是 json.Number
  • 可以安全转成 int64string
css 复制代码
num, _ := extra2["oldTask"].(json.Number).Int64()

方案 3:使用 struct 明确类型

go 复制代码
type RiskExtra struct {
	OldTask int64 `json:"oldTask"`
}
  • 避免 map[string]interface{} → float64
  • JSON 反序列化会直接解析为 int64

✅ 结论

  1. Go map[string]interface{} + JSON 是大整数丢失精度的高发场景
  2. 精度丢失的原因:JSON 默认解析数字为 float64
  3. 解决方案:
  • 使用字符串存储大整数
  • 使用 json.Number
  • 或者尽量使用 struct 明确类型
相关推荐
WeiXiao_Hyy25 分钟前
成为 Top 1% 的工程师
java·开发语言·javascript·经验分享·后端
苏渡苇31 分钟前
优雅应对异常,从“try-catch堆砌”到“设计驱动”
java·后端·设计模式·学习方法·责任链模式
long31643 分钟前
Aho-Corasick 模式搜索算法
java·数据结构·spring boot·后端·算法·排序算法
rannn_1111 小时前
【苍穹外卖|Day4】套餐页面开发(新增套餐、分页查询、删除套餐、修改套餐、起售停售)
java·spring boot·后端·学习
短剑重铸之日1 小时前
《设计模式》第十一篇:总结
java·后端·设计模式·总结
Dragon Wu2 小时前
Spring Security Oauth2.1 授权码模式实现前后端分离的方案
java·spring boot·后端·spring cloud·springboot·springcloud
一个有梦有戏的人3 小时前
Python3基础:进阶基础,筑牢编程底层能力
后端·python
爬山算法3 小时前
Hibernate(88)如何在负载测试中使用Hibernate?
java·后端·hibernate
独断万古他化3 小时前
【Spring 原理】Bean 的作用域与生命周期
java·后端·spring
我爱加班、、3 小时前
Websocket能携带token过去后端吗
前端·后端·websocket