Go的json.Unmarshal默认将数字转float64导致雪花ID精度丢失，根本原因是float64无法精确表示超2^53-1的大整数；必须用json.Decoder.UseNumber()或json.Number/string字段配合前端字符串传输才能避免。
Go 的 json.Unmarshal 默认把数字转成 float64，雪花 ID（如 1896876827460800512）一进一出就丢末几位——这不是 Gin 的锅，是标准库行为；必须显式接管解码逻辑，否则前端拿到的 ID 已经错了。
为什么 Gin.BindJSON 会 silently 丢精度
Gin 的 ctx.BindJSON() 底层调用 json.Unmarshal()，而后者对 JSON 中的数字字段不做类型提示，默认走 float64 路径。一旦 ID 超过 2^53 - 1（约 9e15），float64 就无法精确表示整数位，比如 1896876827460800512 可能变成 1896876827460800500。
常见错误现象：
- 前端传
{"id": "1896876827460800512"}（字符串），后端却收到int64(1896876827460800500) - 结构体字段声明为
ID int64或ID json.Number，但没配UseNumber()，照样丢精度 - 用
map[string]interface{}接收再断言，却直接写v.(float64)，panic 或错值
在 Gin 中启用 json.Number 的正确姿势
不能依赖 BindJSON()，得在中间件里提前用 json.NewDecoder().UseNumber() 替换原始 body，并把解析结果塞回 context。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 写一个中间件，在
ctx.Request.Body被读取前，用bytes.NewReader(b)构造新 reader，喂给json.NewDecoder().UseNumber() - 解析结果存到
ctx.Set("raw_json", parsedMap)或自定义结构体，避免重复解析 - 后续 handler 中不再调
BindJSON()，改用ctx.MustGet("raw_json")+ 类型断言 - 若字段已知（如
id、trace_id），更推荐结构体字段声明为ID json.Number `json:"id"`，然后调u.ID.Int64()—— 它内部做溢出检查，比手写strconv.ParseInt(u.ID.String(), 10, 64)更稳
struct 字段用 string 还是 json.Number？
两者都绕开 float64，但语义和容错不同：
-
ID string `json:"id,string"`：要求前端必须发{"id": "123..."}（带引号），否则解析失败；适合强约定场景，且能天然兼容超int64的 ID（如 128 位） -
ID json.Number `json:"id"`：接受裸数字或字符串，内部存为字节切片；调.Int64()时才校验范围，失败返回 error；更适合渐进式改造 - 别混用：
json.Number字段加",string"标签会 panic；string字段加",string"才生效
数据库与传输链路必须全程 uint64 语义
精度丢失不止发生在 JSON 解析，还藏在存储和 ORM 层：
- MySQL 字段必须是
BIGINT UNSIGNED，用BIGINT SIGNED会导致高位为 1 的 ID（如0x8000000000000000）被解释成负数，查不到也插不进 - Gin handler 里生成的 ID 是
uint64，但结构体字段若声明为int64，赋值时会静默截断；应统一用uint64或string - 如果用了 GORM，确保
id字段 tag 里有gorm:"primaryKey;type:bigint unsigned"，否则 migrate 自动建表可能用错类型
最容易被忽略的一点：时钟回拨处理和 Node 初始化不在这个链路里，但一旦 snowflake.Node.GetID() panic，整个 HTTP 请求就挂了——所以 Node 必须全局复用、带时间函数替换、nodeID 外部统一分配，这些得在 Gin 启动前做完，而不是等第一个请求才初始化。
