Go json.Decoder UseNumber UseNumber 后类型断言为什么要改成 json.Number

如果一个 JSON 结构要用 map[string]any 接收，默认解码时数字通常会落成 float64。一旦在 json.Decoder 上调用 UseNumber()，数字就会保留为 json.Number。所以旧代码里的 value.(float64) 会失败，正确迁移方式是先断言为 json.Number，再按业务需要调用 String()、Int64() 或 Float64()。

先看清：UseNumber 改变了哪一层类型

动态解码的关键在于目标是 any。标准库在没有额外设置时，会把 JSON 数字转换成 float64；调用 UseNumber 后，解码器会把数字字面量交给 json.Number 保存。对象、数组和字符串的处理并不会因为这个调用突然改变。

package main

import (
    "encoding/json"
    "fmt"
    "strings"
)

func main() {
    input := `{"count":9007199254740993,"ratio":1.25}`

    // 默认模式把动态数字放进 float64，超出精确整数范围时可能丢失信息。
    var normal map[string]any
    _ = json.Unmarshal([]byte(input), &normal)
    fmt.Printf("默认 count: %T %v\n", normal["count"], normal["count"])

    // UseNumber 保留 JSON 数字字面量，后续再由业务决定如何转换。
    dec := json.NewDecoder(strings.NewReader(input))
    dec.UseNumber()
    var precise map[string]any
    if err := dec.Decode(&precise); err != nil {
        panic(err) // 示例直接终止；服务代码应把错误返回给调用方。
    }
    fmt.Printf("UseNumber count: %T %v\n", precise["count"], precise["count"])
}

因此，失败往往长这样：

// UseNumber 后这里不能再假定 value 是 float64。
count := value.(float64) // 运行时会因实际类型为 json.Number 而 panic

这不是 JSON 数字变成了字符串，也不是 UseNumber 改变了字段名；它只是延后了数值转换。类型断言必须和解码器的策略一致。

把类型断言改成 json.Number，再选择转换出口

json.Number 是一个保存 JSON 数字字面量的类型。它提供的三个入口用途不同：String() 不做数值转换，适合继续传递或审计原文；Int64() 适合明确要求有符号 64 位整数的字段；Float64() 适合允许浮点近似的比例、坐标或统计值。

func readCount(values map[string]any) (int64, error) {
    value, ok := values["count"]
    if !ok {
        return 0, fmt.Errorf("缺少 count") // 先区分缺字段和类型错误。
    }

    number, ok := value.(json.Number)
    if !ok {
        return 0, fmt.Errorf("count 类型为 %T，不是 json.Number", value)
    }

    count, err := number.Int64()
    if err != nil {
        return 0, fmt.Errorf("count 不是可用整数 %q: %w", number.String(), err)
    }
    return count, nil
}

如果字段可能来自多个历史接口，可以在迁移期同时接受 json.Number 和旧的 float64，但要把兼容逻辑放在边界函数里，不要让整个业务层到处出现两套断言。等所有入口统一启用 UseNumber 后，再删除旧分支。

迁移时不要把结构化字段也改成动态类型

UseNumber 只在目标包含 any 或 interface{} 时最明显。对于已经知道字段类型的结构体，直接声明 int64、float64 或自定义类型通常更清楚，标准库会按字段类型完成解码。

type Event struct {
    ID    int64   `json:"id"`
    Score float64 `json:"score"`
}

func decodeEvent(data []byte) (Event, error) {
    var event Event
    if err := json.Unmarshal(data, &event); err != nil {
        return Event{}, fmt.Errorf("解析事件: %w", err) // 结构化字段在入口统一报错。
    }
    return event, nil
}

更稳妥的边界是：固定协议用结构体，扩展字段或插件参数才用 map[string]any。如果同一个服务同时使用 json.Unmarshal 和 Decoder，不要误以为全局开启了 UseNumber；它是某一个 Decoder 实例的设置。

四个检查点，避免迁移后又出现类型 panic

1. 搜索所有 .(float64) 和 .(json.Number)，确认它们对应的解码入口。
2. 对大整数测试 String() 路径，不要拿 Float64() 做中间转换。
3. 对 Int64() 的小数、负数和越界值分别保留错误处理，不要直接忽略 err。
4. 为缺字段、nil、旧的 float64 和新的 json.Number 各准备一个测试样例。

相关问题

UseNumber 会让所有数字都变成字符串吗？

不会。动态数字变成的是 json.Number，它可以保留字面量，也能显式转换为整数或浮点数；JSON 中的字符串仍然是 Go 的 string。

json.Number 能直接和 int64 比较吗？

不能。先调用 Int64() 并处理错误，再比较结果；如果要保留原样，就比较 String() 返回的文本。

结构体字段会因为 UseNumber 改变类型吗？

通常不会。UseNumber 主要影响解码到 any 的数字；结构体字段仍按声明的 Go 类型解码，并在不匹配时返回解析错误。