Go strconv.NumError 怎么拿到具体转换字段

调用 strconv.ParseInt、strconv.ParseFloat 失败时，err.Error() 往往只是一整句文本。要拿到“哪个转换函数失败、用户传入了什么、失败原因是什么”，应使用 errors.As 把错误取回 *strconv.NumError，再读取它的 Func、Num 和 Err 字段。不要靠切割错误字符串来猜字段。

先判断 err 里是不是 *strconv.NumError

下面的例子故意把 bitSize 设为 8，并传入超出 int8 范围的字符串。这样既能看到错误对象，也能区分“输入不是数字”和“数字太大”两类问题。

package main

import (
    "errors"
    "fmt"
    "strconv"
)

func inspect(raw string) {
    // bitSize=8 表示目标范围按 int8 判断，便于演示范围错误。
    value, err := strconv.ParseInt(raw, 10, 8)
    if err == nil {
        fmt.Println("value:", value)
        return
    }

    var numErr *strconv.NumError
    // errors.As 能沿着包装链寻找 *strconv.NumError，比直接断言更稳妥。
    if errors.As(err, &numErr) {
        fmt.Println("Func:", numErr.Func)
        fmt.Println("Num:", numErr.Num)
        fmt.Println("Err:", numErr.Err)
        return
    }

    // 非 NumError 仍要保留兜底分支，避免丢失未知错误。
    fmt.Println("other error:", err)
}

func main() {
    inspect("256")
    inspect("2x")
}

这里的关键不是把 err 强行断言成某个类型，而是让 errors.As 沿着错误包装链查找目标类型。当前错误若来自 ParseInt、ParseUint、ParseFloat 或 ParseComplex，通常都能得到对应的 *strconv.NumError。

Func、Num、Err 三个字段分别看什么

NumError 是一个记录转换失败的结构体，三个字段的用途很明确：

err.Error() 适合给日志或调试输出看，但不适合当作程序接口。错误文本可能包含引号和具体输入；业务判断应直接使用字段与标准错误值。

用 errors.Is 区分语法错误和范围错误

拿到 NumError 后，不要只比较 numErr.Err.Error() 的字符串。标准库提供的 strconv.ErrSyntax 表示输入语法不符合目标类型，strconv.ErrRange 表示值超出了指定大小的可表示范围。

func message(raw string) string {
    // 先保留 err，不能因为 ParseInt 返回了数值就认为转换成功。
    _, err := strconv.ParseInt(raw, 10, 8)
    if err == nil {
        return "输入有效"
    }

    if errors.Is(err, strconv.ErrSyntax) {
        // 语法错误适合提示用户检查数字格式。
        return "请输入合法的整数"
    }
    if errors.Is(err, strconv.ErrRange) {
        // 范围错误要提示可接受区间或调整目标类型。
        return "整数超出当前字段的取值范围"
    }
    return "数字转换失败"
}

由于 *strconv.NumError 实现了 Unwrap，errors.Is(err, strconv.ErrSyntax) 可以直接从外层错误找到底层原因。若你只比较 err == strconv.ErrSyntax，通常会因为外层是 *NumError 而判断失败。

把字段接入输入校验日志

在表单、配置文件或批量导入场景中，推荐把“内部诊断”和“对外提示”分开。内部日志记录 Func、Num 和 Err，方便定位是哪一个字段传入了异常值；对外只返回不泄露敏感内容的提示，必要时给输入字段编号。

还要注意 ParseInt 的返回值：范围错误时结果可能已经接近目标类型的边界，但它不能替代成功标志。只有 err == nil 时才把结果写入业务对象；否则应保留原始输入，修正格式或调整明确的目标范围后再重试。

常见问题

为什么不直接用 err.(*strconv.NumError)？

没有错误包装时直接断言可以工作，但调用方或中间层可能用 %w 包装错误。errors.As 能沿包装链查找类型，更适合公共校验函数。

NumError.Num 是转换后的数字吗？

不是。Num 保存的是传给转换函数的原始字符串；转换后的结果仍由 ParseInt 等函数的返回值提供。

什么时候需要记录 Num 字段？

当输入来自 CSV、配置或表单时，它能帮助定位具体坏值；若原始输入可能包含密码、令牌等敏感内容，应先脱敏再写日志。

因此，拿具体转换字段的稳定写法就是：先用 errors.As 取得 *strconv.NumError，读取 Func、Num、Err，再用 errors.Is 做原因分支。这样既不依赖错误文本，也能让提示、日志和业务范围判断各自承担清晰职责。