优先选 strconv.ParseInt：它支持任意进制（2～36）和位宽（0/32/64），而 Atoi 仅限十进制 int，底层即 ParseInt(s,10,0)，灵活性不足。
字符串转整数时，strconv.Atoi 和 strconv.ParseInt 该怎么选？
strconv.Atoi 看起来最方便，但只支持十进制 int 类型，且底层调用的就是 strconv.ParseInt(s, 10, 0)。一旦遇到十六进制、八进制或需要明确位宽（比如 int32）的场景，它就无能为力。
strconv.ParseInt 更灵活：第一个参数是字符串，第二个是进制（2～36），第三个是位宽（0 表示平台默认，32 或 64 显式指定）。返回 int64 和 error，需手动类型断言或转换。
- 读配置文件里带
0x前缀的十六进制数？用strconv.ParseInt(s, 0, 64)—— 进制设为0会自动识别0x/0o/0b - 解析 JSON 中明确要求
int32的字段？别直接转int再赋值，先用ParseInt(s, 10, 32)，再int32(v) - 忽略错误直接取值？不行。
strconv.Atoi失败返回0，但0本身可能是合法输入，必须检查err != nil
浮点数互转，strconv.ParseFloat 的精度陷阱在哪？
Go 的 float64 是 IEEE 754 双精度，但字符串转浮点时，strconv.ParseFloat(s, bitSize) 的 bitSize 参数不是“保留几位小数”，而是指定目标类型位宽：32 得 float32，64 得 float64。
常见误用是以为传 2 就能保留两位小数——实际会 panic。真正控制显示精度得靠格式化，比如 fmt.Sprintf("%.2f", f)，但那是字符串操作，不改变数值本身。
立即学习“go语言免费学习笔记（深入）”；
- 从 HTTP query 解析
price=19.99？用strconv.ParseFloat(s, 64)，然后做业务校验（比如是否 ≥ 0） - 存入数据库前确保是
float32？用ParseFloat(s, 32)，注意可能丢失精度（float32约 7 位有效数字） - 字符串是
"inf"或"nan"？ParseFloat能正确解析，但后续计算需自行判断math.IsInf/math.IsNaN
strconv.Itoa 和 strconv.FormatInt 性能与适用边界
strconv.Itoa(i) 是 strconv.FormatInt(int64(i), 10) 的快捷封装，仅支持十进制 int。它简洁，但隐藏了类型转换：如果 i 是 int32 或 uint64，编译器会隐式转成 int 或 int64，可能引发溢出（尤其在 int 是 32 位的环境）。
更安全的做法是显式使用 FormatInt 或 FormatUint：前者接受 int64 + 进制，后者接受 uint64 + 进制。它们不依赖平台 int 位宽，行为确定。
- 处理
time.Unix()返回的int64时间戳？直接strconv.FormatInt(ts, 10)，别用Itoa（可能截断） - 生成十六进制 ID（如
"a1b2c3"）？strconv.FormatInt(id, 16)，小写；要大写就用strings.ToUpper包一层 - 拼接大量数字字符串？
strconv方法比fmt.Sprintf快得多，但若需复杂格式（如补零），fmt.Sprintf("%08d", n)更直观
错误处理不是可选项，strconv 所有解析函数都必须检查 err
所有 ParseXxx 函数（ParseInt、ParseFloat、ParseBool 等）和 Atoi 都返回 error。忽略它，等于默认接受任意非法输入为 “0” 或 “false”，这在配置解析、API 参数校验中极易埋雷。
典型错误现象：前端传来空字符串 "" 或纯空白 " \t\n"，ParseInt 返回 0, strconv.ParseInt: parsing "": invalid syntax；但若没检查 err，程序就拿 0 当合法值继续执行。
- 批量解析 CSV 数字列？用循环 +
if err != nil { log.Printf("row %d: %v", i, err); continue } - CLI 工具接收用户输入？
if n, err := strconv.ParseInt(os.Args[1], 10, 64); err != nil { fmt.Fprintln(os.Stderr, "invalid number:", err); os.Exit(1) } - JSON unmarshal 后二次校验？即使
json.Unmarshal成功，字段仍可能是空字符串，需额外调用strconv并检查err
最常被跳过的其实是 strconv.ParseBool——它只认 "true"/"false"（大小写敏感）、"1"/"0"，其他如 "yes"、"on" 都会报错。别假设前端传来的布尔字符串一定合规。
