strconv.ParseInt 会分配内存的根本原因是其内部调用 strconv.atoi 时，解析失败会构造包含原始字符串字段的 strconv.NumError，触发堆分配；即使成功，错误路径仍可能已分配。
为什么 strconv.ParseInt 会分配内存？
根本原因在于 strconv.ParseInt 内部会调用 strconv.atoi，而后者在解析失败时会构造 strconv.NumError 实例——这个错误对象包含一个 string 字段（记录原始输入），触发堆上分配。即使你用 err == nil 判断成功，只要函数内部走过错误路径（比如开头有空格、符号位置异常），就可能已分配内存。
更隐蔽的是：Go 1.20+ 对部分短字符串做了栈上逃逸优化，但 ParseInt 的错误构造逻辑仍强制堆分配，无法绕过。
用 strconv.ParseInt 前先做快速校验
不是所有字符串都需要走完整解析流程。对已知格式（如纯数字、固定长度 ID）可跳过错误路径，避免触发分配。
- 若确定字符串只含 ASCII 数字（不含
'+'/'-'），直接遍历字节验证：for i := range s { if s[i] < '0' || s[i] > '9' { return 0, fmt.Errorf("invalid digit") } } - 若允许带符号，先检查首字符是否为
'-'或'+'，再验证后续字节 - 长度超限（如 >19 位）直接拒绝，避免进
ParseInt后因溢出构造错误
用 fmt.Sscanf 替代？不推荐
fmt.Sscanf 看似无显式错误构造，但它底层依赖 fmt 的通用解析器，会分配 fmt.scanner 和缓冲区，实测分配量比 ParseInt 更高。
立即学习“go语言免费学习笔记（深入）”；
唯一例外是极短固定格式（如 "%d" + 长度 ≤3 的字符串），但不可控且无性能优势。实测中，哪怕输入是 "123"，Sscanf 仍比校验后调用 ParseInt 多分配 2~3 个对象。
真正零分配的方案：手写解析（仅限可信输入）
当输入来源绝对可控（如 RPC 序列化、DB 字段约束保证纯数字），可完全跳过标准库：
func atoi64(s string) (int64, bool) {
if len(s) == 0 {
return 0, false
}
neg := false
start := 0
if s[0] == '-' {
neg = true
start = 1
} else if s[0] == '+' {
start = 1
}
var n int64
for i := start; i < len(s); i++ {
c := s[i]
if c < '0' || c > '9' {
return 0, false
}
digit := int64(c - '0')
if n > (1<<63-1-digit)/10 { // 溢出检查
return 0, false
}
n = n*10 + digit
}
if neg {
n = -n
}
return n, true
}这个函数不构造任何堆对象，返回 bool 而非 error，调用方需自行处理失败逻辑。注意：溢出检查必须手动写，int64 最大值是 9223372036854775807，最小值是 -9223372036854775808，直接乘加会溢出导致结果错误。
手写解析的代价是丧失标准库的兼容性（比如对 " 123" 这类带空格的容忍），所以只适用于输入格式严格受控的场景。一旦输入可能含非法字符或空格，还是得回退到带校验的 ParseInt 调用。
