应优先使用strconv.atoi处理明确为十进制、范围可控且无需指定精度的简单场景；需控制进制、位宽或处理前缀时，必须用strconv.parseint。
strconv.Atoi 是 Go 中最轻量、最常用的字符串转整型方式，但它不是万能的——用错场景或忽略边界条件，立刻 panic 或静默出错。
什么时候该用 strconv.Atoi，而不是 strconv.ParseInt
直接选 strconv.Atoi 的前提是：你明确只要十进制、目标类型就是 int（即平台原生整型）、且不关心位宽细节。
- 它等价于
strconv.ParseInt(s, 10, 0)，其中0表示“用当前平台int的位宽”，所以 64 位系统返回int64值，32 位系统返回int32值 - 如果你需要固定为
int32或int64（比如和 protobuf 字段对齐），必须用ParseInt(s, 10, 32)或ParseInt(s, 10, 64) - 如果输入可能是十六进制（如
"ff"）、二进制（如"1010"）或带前缀的（如"0xFF"），Atoi直接失败，得用ParseInt并手动处理前缀
strconv.Atoi 常见失败原因和对应修复
错误不是偶然发生的，而是由输入格式决定的。以下情况都会让 err != nil：
- 字符串含空格：
" 123"或"123 "→ 用strings.TrimSpace预处理 - 含小数点：
"123.45"→Atoi不支持浮点，改用strconv.ParseFloat再转整 - 含逗号分隔符：
"1,234"→ 先strings.ReplaceAll(s, ",", "") - 空字符串
""或纯符号"+"、"-"→ 检查长度和内容再调用 - 超出
int范围：比如在 32 位环境里传"2147483648"→ 错误信息是"value out of range"，此时应换用ParseInt(s, 10, 64)并自行截断或报错
为什么不能忽略 err 判断？
strconv.Atoi 即使失败，也会返回一个 int 值（零值），但这个值毫无意义。依赖它做计算会导致逻辑错误，且无法从值本身察觉失败。
- 例如：
num, err := strconv.Atoi("abc")→num == 0，err != nil；若只读num就当成 0 处理，业务就错了 - Go 不允许变量声明后未使用，所以编译器会强制你处理
err，这是保护机制，不是负担 - 常见写法是：
if err != nil { return 0, err }或log.Fatal(err)，取决于上下文是否允许失败
性能与可维护性取舍点
表面上 Atoi 比 ParseInt 少两个参数，更简洁；但实际差异微乎其微，真正影响可维护性的是语义清晰度。
- 如果函数签名里写
func parseID(s string) (int, error)，用Atoi更贴切——ID 就是十进制整数 - 如果解析配置项如
"timeout = 30s"中的数字，且要求必须是int64，硬套Atoi反而埋下跨平台隐患 - 团队代码里混用两者时，建议统一加注释说明选择理由，比如：
// Atoi: ID 必为正十进制，无需进制/位宽控制
Atoi 当作“简单版 ParseInt”来降级使用，它的设计意图很明确：只做一件事，且做好。越早看清这个边界，越少在 runtime 里追奇怪的 0 值。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
