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" 前缀)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 是 *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)"123" 或 "1,000"),需预处理最常被跳过的一步是 trim 空格 —— 生产环境日志、API 输入、配置文件值往往带不可见空白,直接解析必错。