go字符串转数字首选strconv包，因fmt.sscanf易panic、类型断言不安全；strconv.atoi仅支持十进制int且精度/进制不灵活，应按需选用parseint/parseuint/parsefloat并正确处理错误、空格、科学计数法及性能问题。
Go 里字符串转数字，首选 strconv 包，别用 fmt.Sscanf 或类型断言硬凑——它不处理错误细节，也容易 panic。
为什么 strconv.Atoi 不够用？
strconv.Atoi 看似最简，但它只支持十进制 int，且返回 int（在 32 位系统上是 int32，64 位是 int64），实际项目中常需要明确精度或进制。
- 输入是
"0xFF"？atoi直接报错，得换strconv.ParseInt(s, 16, 64) - 要转成
int32但值超范围？Atoi返回int64再强转会静默截断，而ParseInt(s, 10, 32)明确返回ERANGE - 字符串带空格如
" 42 "？Atoi失败，得先strings.TrimSpace
strconv.ParseFloat 的精度陷阱
它返回 float64，但第二个参数指定的是“期望精度”，不是小数位数——传 32 得到 float32 值（可能丢失精度），传 64 才是完整解析。
- 错误写法：
f, _ := strconv.ParseFloat("1.234567890123456789", 32)→ 实际存的是1.2345679 - 正确做法：先用
64解析，再按需转float32(f)，并自己判断是否溢出 - 科学计数法如
"1e-5"能正常解析；但"1.2e"会报invalid syntax
错误处理不能只写 if err != nil
strconv 的错误类型是 *strconv.NumError，它带字段 Func、Num、Err，对调试和用户提示很关键。
- 直接打印
err.Error()得到strconv.ParseInt: parsing "abc": invalid syntax，但没说明是哪个函数调的 - 建议检查
err.(*strconv.NumError).Func来区分是ParseInt还是ParseUint出的问题 - 用户输入场景下，用
err.(*strconv.NumError).Num提取原始字符串，用于日志或友好提示，比如 “无法解析数字：‘{{num}}’”
性能敏感时，避免重复分配
strconv 函数内部会做字符串切片和临时缓冲，高频调用（如日志解析、网络协议解包）要注意：
- 别在循环里反复调
strconv.ParseInt(string(b[:n]), 10, 64)—— 如果b是[]byte，优先用strconv.ReadInt配合bytes.Reader流式读，或手写简易解析（仅限已知格式，如纯数字 ASCII） -
strconv.Itoa比fmt.Sprintf("%d", n)快 3–5 倍，但反向（字符串→整数）没有对应“itoa 级别”的无分配 API，只能接受它 - 如果确定输入永远合法（如配置文件预校验过），可加
//nolint:errcheck，但别省略变量名，至少写成n, _ := strconv.ParseInt(s, 10, 64)，方便后续加检查
真正难的不是选哪个函数，而是想清楚：这个字符串从哪来？有没有空格或前导零？要不要支持十六进制？超出范围时该报错还是截断？这些决定比写一行 ParseInt 影响更大。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
