strconv.Atoi不能直接使用，必须检查error，因为它在解析失败时返回0和error，忽略error会导致业务逻辑误用0作为有效值；它仅支持十进制、不自动trim空格、位宽依赖平台且无法指定int64。
strconv.Atoi 为什么不能直接用，而必须检查 error
它从不 panic，但忽略 err 会导致后续逻辑用 0 当有效值——比如 strconv.Atoi("abc") 返回 0, error，若直接赋给计数器或 ID 字段，业务就悄悄错掉了。
- 所有外部输入（HTTP query、JSON 字段、配置文件）都必须走
if err != nil分支，哪怕你“觉得不会出错” -
strconv.Atoi只支持十进制，不识别"0x10"、"1e2"、"123px"，也不自动 trim 空格；传入" 123 "会报strconv.ParseInt: parsing " 123 ": invalid syntax - 它底层调用的是
strconv.ParseInt(s, 10, intSize)，所以位宽取决于当前平台的int大小（32 或 64），跨平台时行为一致，但无法指定为int64
ParseFloat 的 bitSize 参数不是“保留几位小数”，而是类型位宽
传 32 得 float32，传 64 得 float64；误传会导致精度丢失甚至 panic，比如 strconv.ParseFloat("9999999999.123456789", 32) 解析后变成约 1e10，因为 float32 仅支持 ~7 位有效十进制数字。
- 除非明确内存受限且数值范围小（如嵌入式传感器原始读数），否则统一用
64 - 科学计数法字符串（
"1.23e-4"）完全支持，无需额外处理 - Go 1.22+ 对非法格式更严格：
"1.23e"现在明确报strconv.ParseFloat: parsing "1.23e": invalid syntax，旧版本可能静默截断
ParseBool 只认四个值，别指望它兼容业务语义
strconv.ParseBool 仅接受 "true"、"false"、"1"、"0"（大小写不敏感），不认 "yes"、"on"、"enabled"，也不处理空字符串或 "null"。这不是 bug，是设计取舍：避免把业务规则塞进基础转换层。
- 如果 API 返回
"active": "yes"，得自己写映射逻辑，不能硬套ParseBool - 错误类型是
*strconv.NumError，可通过errors.Is(err, strconv.ErrSyntax)判断是否为语法错 - 想快速验证字符串是否可转 bool，别用
ParseBool+ recover，直接用strings.EqualFold(s, "true") || s == "1"更轻量
高频转换场景下，避免反复分配字符串
strconv.Itoa 和 strconv.FormatInt 每次都新建字符串，对高频日志、序列化、指标打点等场景有 GC 压力。这时应优先用 strconv.AppendInt 或 fmt.Appendf 写入预分配的 []byte 缓冲区。
立即学习“go语言免费学习笔记（深入）”；
-
strconv.Itoa(123)等价于strconv.FormatInt(int64(123), 10)，但前者无参数控制，后者可选进制 - 拼接多个数字字段时，用
buf := make([]byte, 0, 128); buf = strconv.AppendInt(buf, x, 10)比多次+更省内存 -
strconv.FormatFloat(x, 'f', 2, 64)的第三个参数是小数位数（仅对'f'和'e'生效），和ParseFloat的bitSize完全无关，别混淆
strconv 不做 trim，也不区分“格式错”和“溢出错”，得靠 errors.As(err, &strconv.NumError{}) 拿到 Func 和 Err 字段才能精准响应。 
