strconv.atoi与parseint的错误分支开销在于运行时必然执行的路径检查，包括空字符串、非法字符和溢出判断，且无法被编译器优化，error作为接口类型在保留时会触发小对象分配。
strconv.Atoi 与 strconv.ParseInt 的错误分支实际开销在哪
Go 中 string 转数值没有“强转”一说，strconv.Atoi 和 strconv.ParseInt 的错误分支不是编译期跳过，而是运行时必然执行的路径检查——空字符串、非法字符、溢出都会触发 error 返回，且这部分逻辑无法被编译器优化掉。
-
strconv.Atoi("123")内部调用ParseInt(s, 10, 0)，先做进制校验，再逐字节扫描，遇到非数字立即返回strconv.ErrSyntax -
strconv.ParseInt("999999999999999999999", 10, 64)在解析完所有字符后才检查是否溢出（通过比较当前值与math.MaxInt64），此时已完成全部计算和临时变量分配 - 错误分支本身不额外分配堆内存，但 error 值是接口类型，底层包含一个字符串字段；若 error 被保留（如 log 或 return），会触发一次小对象分配
为什么 int(float64) 不报错但 string→int 却必须 check error
数值类型间转换如 int(float64(3.14)) 是纯位操作，编译器生成 mov + trunc 指令，无运行时检查；而 string 到 int 是解析行为，涉及字符合法性、进制、范围三重校验，错误不可静态预判。
-
int(1e100)得到 0 —— 编译通过，运行时静默截断，结果未定义但不 panic -
strconv.Atoi("1e100")直接返回strconv.ErrSyntax，因为e不是合法十进制数字字符 - 真正危险的是
strconv.ParseInt("9223372036854775807", 10, 64)后面加个1：它能解析成功，但最终值溢出，返回strconv.ErrRange
高频 string→int 场景下 error 处理的性能陷阱
错误分支本身不慢，慢在开发者常把 error 处理写成阻塞式 fallback 或重复解析，尤其在 HTTP query 解析、日志字段提取等场景中。
- 别在循环里反复调用
strconv.Atoi(s)然后if err != nil { continue }—— 即使 99% 成功，每次调用仍要走完整扫描逻辑 - 对已知格式字符串（如固定长度数字 ID），可先用
bytes.IsDigit快速筛掉非法字符，再进ParseInt，减少 error 分支进入深度 - 避免把
err.Error()直接拼进日志：它会触发字符串构造和内存分配；用fmt.Sprintf("parse failed: %v", err)更可控
string 转数值时最易被忽略的边界 case
不是所有 “看起来像数字” 的字符串都能被安全解析，这些 case 在测试中常被漏掉，上线后暴露为 panic 或静默错误。
- 前导空格：
strconv.Atoi(" 123")返回strconv.ErrSyntax，strings.TrimSpace必须前置 - 正号：
strconv.Atoi("+123")成功，但strconv.ParseInt("+123", 10, 64)也成功 —— 注意Atoi只支持十进制，不接受+，实际会失败 - Unicode 数字：
"１２３"（全角数字）会被当成非法字符，ParseInt不做 Unicode normalization - 零长度：
strconv.Atoi("")不是返回 0，而是strconv.ErrSyntax—— 这个 error 容易被 if err == nil 掩盖
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
