在 Go 中使用 json.Unmarshal 解析 JSON 数组时，所有数字（无论 JSON 中是整数还是浮点数）均被默认反序列化为 float64 类型，这是由 JSON 规范和 Go 标准库设计共同决定的确定性行为。
在 go 中使用 `json.unmarshal` 解析 json 数组时，所有数字（无论 json 中是整数还是浮点数）均被默认反序列化为 `float64` 类型，这是由 json 规范和 go 标准库设计共同决定的确定性行为。
Go 的 encoding/json 包在将 JSON 数据解码为 []interface{} 或 map[string]interface{} 等通用结构时，采用一套预定义的类型映射规则。根据 官方文档 明确说明：
To unmarshal JSON into an interface value, Unmarshal stores one of these in the interface value:
- bool, for JSON booleans
- float64, for JSON numbers
- string, for JSON strings
- []interface{}, for JSON arrays
- map[string]interface{}, for JSON objects
- nil, for JSON null
这一设计的根本原因在于：JSON 规范本身不区分整数与浮点数。RFC 8259 将数字定义为“一个带可选符号、可选小数部分和可选指数部分的十进制数”，即所有 JSON 数字在语法层面都属于同一抽象类型——其语义精度由解析器和应用层共同约定。Go 选择统一使用 float64（IEEE 754 双精度）作为底层表示，既保证了对标准 JSON 数字范围（≈ ±1.8×10³⁰⁸）的充分覆盖，又避免了因整数位宽（如 int32/int64）引发的兼容性歧义。
因此，在你的示例中：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
[1, 2.5, "aaa", true, false]
虽然 1 在 JSON 中是整数字面量，但 json.Unmarshal 仍将其解析为 float64(1.0)，故 reflect.TypeOf(arg).Kind() 返回 float64，而非 int64。这也解释了为何输出中第一个元素显示为 float64 1。
如何正确识别并还原整数值？
若业务逻辑需区分整数与浮点数（例如做类型敏感的参数校验或转换），不能依赖 reflect.Kind() 直接判断原始 JSON 类型，而应通过值的数学特性进行推断：
for _, arg := range x {
switch v := arg.(type) {
case float64:
// 检查是否为整数值：无小数部分且在 int64 范围内
if v == float64(int64(v)) &&
v >= math.MinInt64 && v <= math.MaxInt64 {
fmt.Printf("int64 %d\n", int64(v))
} else {
fmt.Printf("float64 %.1f\n", v)
}
case string:
fmt.Printf("string %q\n", v)
case bool:
fmt.Printf("bool %t\n", v)
default:
fmt.Printf("unknown type: %v (kind: %s)\n", v, reflect.TypeOf(v).Kind())
}
}⚠️ 注意事项：
- float64 无法精确表示所有大整数（如超过 2⁵³ 的整数会丢失精度），因此 v == float64(int64(v)) 仅适用于安全整数范围；
- 若需严格保留 JSON 原始格式（如 API 网关场景），建议使用 json.RawMessage 延迟解析，或借助第三方库（如 gjson、jsoniter）提供更细粒度的类型控制；
- 不要尝试用 json.Number（需显式启用 Decoder.UseNumber()）后强制转 int64——它本质仍是字符串解析，仍需自行处理溢出与精度问题。
总之，float64 作为 JSON 数字的统一载体是 Go 的有意设计，而非 bug。理解这一机制，有助于编写健壮、符合预期的 JSON 处理逻辑。
