Go JSON解析int64精度丢失源于json.Unmarshal默认将数字转为float64，其53位精度无法准确表示超过2^53的整数；推荐用json.Number拦截字符串后调用Int64()，或自定义SafeInt64类型实现UnmarshalJSON以精确解析。
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 精确解析，或者想统一处理溢出/非法格式时，封装一个类型更可控。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“go语言免费学习笔记（深入）”；
- 定义新类型如
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 校验——但后者本身就有精度风险。
