最常用 string 转 int 是 strconv.Atoi，但必须检查 error；不可信输入或需指定进制/位宽时用 strconv.ParseInt；JSON 解析优先用结构体直解而非手动转换。
string 转 int 用 strconv.Atoi 最常用，但别直接用在不可信输入上
它快、简洁，适合你确定字符串一定是合法整数的场景，比如配置文件里写死的端口号或版本号。但一旦遇到空字符串、带空格、字母或超范围数字，strconv.Atoi 就 panic 或返回错误，不抛异常而是返回 error 值——这点容易被忽略，写成 i, _ := strconv.Atoi(s) 就埋雷了。
- 正确写法永远检查 error：
i, err := strconv.Atoi(s); if err != nil { /* 处理错误 */ } - 它等价于
strconv.ParseInt(s, 10, 0)，底层转成int（具体是 int32 还是 int64 取决于平台，一般不用管） - 不能处理十六进制、二进制等格式，像
"0xFF"会失败；要支持前缀得用strconv.ParseInt(s, 0, 64)
需要指定位宽或进制时，必须用 strconv.ParseInt
比如解析 HTTP Header 里的 Content-Length，虽然也是十进制，但协议要求是 64 位整数；或者读取用户输入的十六进制颜色码 "FF00AA"。这时候 Atoi 不够用，得上 ParseInt。
- 签名是
func ParseInt(s string, base int, bitSize int) (i int64, err error) -
base = 0表示自动识别前缀："0x"→16，"0"→8，"0b"→2，否则填 2/8/10/16 -
bitSize控制结果类型：填 32 得int32，填 64 得int64；Go 没有int的泛型转换，所以别指望它自动适配目标变量类型 - 注意溢出行为：
"9223372036854775808"（比 math.MaxInt64 大 1）会返回0, strconv.ErrRange，不是 panic
从 JSON 或结构体解码时，别手动转，让 json.Unmarshal 自己干
如果你的 string 其实来自 JSON 字段，比如 {"age": "25"}，而结构体字段定义为 Age int，直接用 json.Unmarshal 是能成功解析的——前提是开启 UseNumber 选项并自己处理，但更简单的是：别把数字字段存成 string。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误：后端 API 返回的 JSON 把数字包成字符串（如
"id": "123"），前端开发者习惯性用map[string]interface{}解，再手动Atoi——这容易漏掉空值或格式错误 - 推荐做法：定义明确 struct，字段类型直接用
int或int64，Go 的json包默认支持 string → number 的宽松解析（只要内容是纯数字） - 如果必须用
interface{}，先断言为string再转，别假设它是float64（那是数字没加引号时的行为）
性能敏感场景下，避免反复分配，考虑用 strconv.AppendInt 反向操作来预估缓冲区
这不是 string→int 的转换，但常被一起问：为什么我批量转换后拼接字符串很慢？因为 strconv.Itoa 每次都 new 一个 string。反过来想，如果你要频繁把 int 写进 byte slice（比如日志拼接、二进制协议编码），strconv.AppendInt 能复用底层数组，减少 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
-
buf := make([]byte, 0, 20); buf = strconv.AppendInt(buf, 12345, 10)—— 结果是[]byte("12345")，且 buf 可复用 - 对 string→int 本身来说，没有“零分配”方案；
Atoi和ParseInt都不分配堆内存（除错误字符串外），所以性能瓶颈通常不在转换函数，而在你是否做了多余检查或错误处理 - 真正卡顿的地方往往是：在 for 循环里对同一 string 反复调用
Atoi，却没缓存结果
转换逻辑本身不复杂，难的是判断该用哪个函数、什么时候该检查 error、以及怎么和周边系统（JSON、HTTP、CLI 参数）配合不翻车。边界情况——空、空格、前导零、负号、溢出、编码格式——永远比文档里写的多。
