strconv.Atoi不能直接转int64，因其返回平台相关int（32/64位），无法保证精度一致；正确方式是用strconv.ParseInt(s, 10, 64)，它明确指定64位、支持错误详情和进制控制。
strconv.Atoi 为什么不能直接转 int64？
因为 Atoi 返回的是平台相关的 int：32 位系统上是 int32，64 位系统上是 int64。你无法保证它和你的目标类型（比如数据库 ID、Unix 时间戳）一致。
常见错误现象：int64(id) = strconv.Atoi(s) 在 32 位环境会静默截断；strconv.Itoa64 根本不存在，编译直接报 undefined: strconv.Itoa64。
- 需要明确得到
int64→ 用strconv.ParseInt(s, 10, 64) - 输入可能带前缀（
"0x1F"、"0b101"）→base=0让它自动识别 - 值可能超范围 →
ParseInt返回ERANGE错误，而Atoi可能只返回截断值 +nil错误 - 字符串含空格（如
" 42 "）→Atoi和ParseInt都不跳过，必须先strings.TrimSpace，但注意这会触发堆分配
ParseInt 和 Atoi 的错误处理差异在哪？
Atoi 是 ParseInt(s, 10, 0) 的快捷封装，但它把错误细节全藏起来了。真正出问题时，你只能看到模糊的 "invalid syntax"，没法知道是哪个字段、什么原始值、调用的是哪个函数。
而 ParseInt 返回的 *strconv.NumError 带有三个关键字段：Func、Num、Err，能精准定位问题。
立即学习“go语言免费学习笔记（深入）”；
- 查具体函数名：
err.(*strconv.NumError).Func == "ParseInt" - 提取原始字符串：
err.(*strconv.NumError).Num（比如"1e5.2"） - 区分底层错误：
err.(*strconv.NumError).Err == strconv.ErrRange或strconv.ErrSyntax - 别写
if err != nil { log.Fatal(err) }—— 丢掉了所有上下文
FormatInt 和 Itoa 怎么选？
Itoa 只接受 int，且固定十进制；FormatInt 接受 int64，支持任意进制（2～36），还兼容 int 类型（只需显式转成 int64）。
性能上两者几乎无差别，但 FormatInt 更统一、更可控。
- 转十进制整数：
strconv.FormatInt(int64(x), 10)比strconv.Itoa(x)多一次类型转换，但语义清晰、跨平台一致 - 转十六进制（如哈希、权限）：
strconv.FormatInt(0755, 8)或strconv.FormatInt(255, 16) - 转二进制用于调试：
strconv.FormatInt(10, 2)→"1010" - 别用
fmt.Sprintf("%d", x)替代 —— 它比FormatInt慢，且必然逃逸到堆
ParseBool 为什么总报 invalid syntax？
ParseBool 只认 8 种字符串："1"、"0"、"t"、"f"、"T"、"F"、"true"、"false"（大小写不敏感）。其它任何值，包括 "yes"、"on"、"enabled"、"YES"，都会返回 strconv.ParseBool: parsing "XXX": invalid syntax。
这不是 bug，是设计如此 —— 它只做严格布尔解析，不做业务映射。
- 上游协议用
"1"/"0"→ 直接用ParseBool - 配置文件用
"enabled"/"disabled"→ 得自己写映射：map[string]bool{"enabled": true, "disabled": false} - 别试图用
strings.ToLower+ParseBool处理"YES"——ParseBool("yes")依然失败 - 日志里打错值时，用
err.(*strconv.NumError).Num看到原始输入，比猜更可靠
