如何在Golang中捕获字符串解析错误_Golangstrconv Atoi Parse方法应用

strconv.Atoi 从不 panic，总是返回 error；真正错误是忽略 error 导致后续逻辑错误。它等价于 ParseInt(s, 10, 0)，仅支持十进制和平台相关位宽；ParseInt 可控进制与位宽，失败返回 *strconv.NumError，含 ErrSyntax 或 ErrRange。

为什么 strconv.Atoi 会 panic？它根本不会 panic

很多人以为 strconv.Atoi 在解析失败时会 panic，实际它**总是返回 error**，从不 panic。真正容易出错的是忽略返回的 error 值，导致后续用到非法的 int（比如 0）引发逻辑错误。

常见错误现象：

• 输入 "abc" 却没检查 error，得到 0 后当成合法数字参与计算
• 把 strconv.Atoi 和 fmt.Sscanf 或类型断言混淆，误以为它类似“强制转换”

正确做法是始终检查 error：

num, err := strconv.Atoi("123")
if err != nil {
    log.Printf("解析失败: %v", err)
    return
}
// 此时 num 才可信

strconv.ParseInt 和 strconv.Atoi 的关键区别在哪

strconv.Atoi 是 strconv.ParseInt(s, 10, 0) 的快捷封装，仅支持十进制、目标位宽由平台决定（通常是 int 的宽度）。一旦需要控制进制或位宽，必须用 strconv.ParseInt。

使用场景举例：

• 解析十六进制字符串 "0xFF" → 用 strconv.ParseInt("FF", 16, 64)（注意去掉 "0x" 前缀）
• 确保结果是 32 位有符号整数 → strconv.ParseInt(s, 10, 32)，返回 int64，需显式转 int32
• 解析超大数字（如时间戳）→ 用 ParseInt(s, 10, 64) 避免溢出

参数差异：

• strconv.Atoi(s string)：无进制、无位宽参数
• strconv.ParseInt(s string, base int, bitSize int)：必须指定进制（2–36）和位宽（0/8/16/32/64）

解析失败时 error 的具体类型和判断方式

返回的 error 是 *strconv.NumError，包含字段 Func（函数名）、Num（原始字符串）、Err（错误原因）。可针对性判断错误类型，而不是只用 err != nil。

常见错误原因：

• strconv.ErrSyntax：格式错误（如 "12a3"、空字符串、只有符号）
• strconv.ErrRange：数值超出目标类型的表示范围（如 "99999999999999999999" 解析为 int32）

示例：区分处理溢出和语法错误

num, err := strconv.ParseInt("1000000000000", 10, 32)
if err != nil {
    if numErr, ok := err.(*strconv.NumError); ok {
        switch numErr.Err {
        case strconv.ErrSyntax:
            log.Printf("格式错误: %q", numErr.Num)
        case strconv.ErrRange:
            log.Printf("数值超出 int32 范围: %q", numErr.Num)
        }
    }
}

性能与兼容性要注意的边界情况

strconv.Atoi 和 ParseInt 都是纯内存操作，无 GC 压力，性能足够高。但以下边界易被忽略：

• 前导空格：两者都**不自动 trim**，" 123" 会报 ErrSyntax；需手动 strings.TrimSpace
• 正负号：支持 "-42" 和 "+42"，但 "+-42" 或 "++42" 是非法的
• 进制合法性：base 必须在 2–36，传入 1 或 37 会导致 panic（不是返回 error）
• Unicode 数字：不支持全角数字或带逗号的格式（如 "１２３" 或 "1,000"），需预处理

最常被跳过的一步是 trim 空格 —— 生产环境日志、API 输入、配置文件值往往带不可见空白，直接解析必错。