strconv.Atoi总返回0是因为忽略error，它不panic但返回0和明确错误；需检查err、trim空格、仅支持十进制整数；ParseInt/ParseFloat参数中base指进制（0可自动识别），bitSize指结果类型位宽（非精度）；Itoa仅支持int，其他用FormatInt等；ParseBool仅认"true"/"false"等严格值。
strconv.Atoi 为什么总返回 0？不是它错了，是你没看 error
绝大多数人第一次用 strconv.Atoi 遇到问题，是因为把返回的 err 当装饰品——它从不 panic，但会悄悄给你一个 0 和一个明确的错误，比如 "strconv.Atoi: parsing \"abc\": invalid syntax"。
常见错误现象：
-
strconv.Atoi(" 123")失败：前导空格不自动 trim，得先strings.TrimSpace -
strconv.Atoi("12.3")失败：它只认整数，小数点直接报错 -
strconv.Atoi("0xFF")失败：不识别进制前缀，十六进制必须用ParseInt
使用场景：适合处理用户输入、HTTP query 参数这类「预期为十进制整数」的字符串。别用它解析配置里的 "timeout_ms": "5000" 这种看似安全但实际可能含空格或非法字符的字段——检查 err 是底线，不是可选项。
ParseInt / ParseFloat 的参数到底怎么填？base 和 bitSize 别乱配
ParseInt 要三个参数：s（字符串）、base（进制）、bitSize（位宽）；ParseFloat 要两个：s 和 bitSize。这里最容易错的是把 bitSize 当成“精度”或“小数位数”。
立即学习“go语言免费学习笔记（深入）”；
参数差异：
-
base=0表示自动识别前缀："0x1F"→ 十六进制，"0755"→ 八进制，"123"→ 十进制 -
bitSize=64不是“保留 64 位小数”，而是指定结果类型为int64或float64—— 业务中几乎都该用 64 -
ParseFloat("1.23456789", 32)可能丢失精度，因为 float32 有效位只有约 7 位十进制数字
实操建议：外部数据一律用 ParseInt(s, 10, 64) + 显式转 int，比 Atoi 多两行，但进制和溢出控制更稳；浮点数统一用 ParseFloat(s, 64)，别碰 32，除非你真清楚自己在做什么。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
Itoa 和 FormatInt 什么时候该用哪个？类型不匹配就编译不过
strconv.Itoa 看似方便，但它只吃 int 类型。一旦你手里是 int64、uint32 或从 JSON 解析出来的数字，直接传进去——编译失败。
常见错误现象：
-
var n int64 = 123; strconv.Itoa(n)→ 编译错误：cannot use n (type int64) as type int -
strconv.Itoa(int(myUint32))在 32 位系统上可能截断（int只有 32 位）
实操建议：
- 确定是
int且只要十进制？用Itoa没问题 - 其他所有情况——用
FormatInt(i, 10)（支持int64）、FormatUint(u, 16)（支持uint64），进制也自由 - 要十六进制大写？
strings.ToUpper(strconv.FormatInt(255, 16))，别指望FormatInt自带大小写开关
ParseBool 支持哪些字符串？"yes"/"on" 会直接报错
strconv.ParseBool 对输入极其严格，只认几个固定值："true"/"false"（不区分大小写）、"1"/"0"、"t"/"f"（大小写均可）。任何其他字符串，比如 "yes"、"on"、"enabled"，都会返回 error。
使用场景：适合解析标准 JSON 布尔字段或明确约定格式的配置项。如果你的 API 文档写着 active: "yes"，那就不能用 ParseBool，得自己写个映射函数。
实操建议：
- 布尔转字符串永远用
FormatBool，它只输出"true"或"false"（全小写），别试图自定义 - 遇到非标准布尔字符串，先做一次
strings.ToLower再 switch，比硬塞给ParseBool更可控 - 别依赖
ParseBool("1") == true来当“通用真值判断”——它不是 JavaScript，没有宽松转换
最常被忽略的一点：所有 Parse* 函数都不自动 trim、不自动识别前缀、不自动降级容错。它不是帮你兜底的工具，而是给你精确控制权的接口——用得好，错误清晰可查；用得糙，bug 就藏在那个被忽略的 err 里。
