反射无法预防int64精度丢失，因json.unmarshal默认将数字解析为float64，此时精度已失；真正有效的是用json.number字符串保真，再配合类型断言和strconv解析。
反射不能预防 int64 精度丢失，它甚至不参与 JSON 解析阶段
Go 的 json.Unmarshal 在解析数字时，**根本不会调用反射来决定类型**。它默认把所有 JSON 数字当作 float64 处理——这个行为发生在反序列化底层逻辑里，reflect.Value 还没出场，精度就已经丢了。你用 reflect.ValueOf(v).Int() 去取一个原本是 float64 的值，得到的是截断后的整数，不是原始大整数。
常见错误现象：json.Unmarshal([]byte(`{"id":4418489049307132905}`), &m) 后，m["id"] 是 float64 类型，值为 4.418489049307133e+18；再用 reflect.ValueOf(m["id"]).Int() 得到的是 4418489049307133184 —— 和原始值差了 279。
- 反射只在值已存在内存中后才起作用，它无法改变 JSON 解析器的默认行为
-
reflect.Value.Int()对float64值做的是强制截断（类似int64(f)），不是“还原” - 如果原始 JSON 数字本就超出
float64精度范围（如 17 位以上整数），reflect拿到的已经是失真数据
真正起效的是 json.Number + 反射辅助转换，而非反射本身
要保住大整数精度，必须在 JSON 解析阶段就绕过 float64 中转。标准做法是用 json.Number 作为中间容器，它本质是字符串，不解析、不计算、不丢失字符。
反射在这里只承担“安全取出并转目标类型”的辅助角色，比如从 map[string]interface{} 里拿到 json.Number 后，再用反射判断其是否可转 int64：
var m map[string]interface{}
json.Unmarshal(data, &m)
if idNum, ok := m["id"].(json.Number); ok {
// 此时 idNum.String() 返回原始 JSON 字符串，无损
if i64, err := idNum.Int64(); err == nil {
// 成功：原始字符串能合法转 int64
}
}
-
json.Number.Int64()内部是字符串解析，不是 float64 转换，所以无精度损失 - 反射仅用于
m["id"].(json.Number)这一步类型断言，确保你拿到的是json.Number而非float64 - 别对
json.Number做reflect.ValueOf().Int()—— 它没有Int()方法，会 panic
用 reflect.Value 转换 interface{} 时，必须先确认 concrete type
从 map[string]interface{} 或 json.RawMessage 取出的值，其 concrete type 才决定你能怎么转。反射只是帮你看清它到底是什么类型，而不是帮你“变成”想要的类型。
例如：
v := reflect.ValueOf(m["id"]) fmt.Println(v.Kind()) // 如果是 float64，默认解析结果 → 输出 float64 fmt.Println(v.Type()) // 输出 float64
- 若
v.Kind() == reflect.Float64，说明 JSON 已经被解析成float64，此时任何后续转换都晚了 - 若
v.Kind() == reflect.String，说明前端发的是字符串（如"id": "4418489049307132905"），这时可用v.String()拿到原始文本，再手动strconv.ParseInt - 若
v.Kind() == reflect.Interface，得先v.Elem()再看里面装的是什么——常见于嵌套结构体字段未导出或指针解引用场景
cast 库比手写反射更安全，但原理仍是类型断言 + 字符串解析
像 github.com/spf13/cast 这类工具，表面看是“一行转 int64”，背后逻辑和反射无关：它先做类型断言（v.(json.Number) 或 v.(string)），再调用 strconv 解析，失败则返回零值或错误。
它不依赖 reflect.Value.Int()，因为那对 float64 不安全。实操建议：
- 优先用
cast.ToInt64E(m["id"])，它内部会按顺序尝试json.Number、string、int64、float64（最后才走 float64 → int64 截断） - 不要用
cast.ToInt64(m["id"])处理可能超精度的大整数——它对float64输入也会静默截断 - 如果你控制不了上游（比如第三方 API 总发 float64），那就只能接受精度损失，或要求对方改用字符串传数字
最易被忽略的一点：精度丢失发生在 JSON 解析那一瞬间，不是在你写 .Int64() 或 reflect.Value.Int() 的时候。所有“转换”操作，都只是对已存在的内存值做解释——如果那个值从一开始就是错的，再怎么反射也救不回来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
