必须检查strconv解析函数的error，否则会因静默失败导致业务逻辑错误；Atoi仅支持十进制int，复杂需求应使用ParseInt/ParseFloat并显式指定base和bitSize；浮点解析需防范NaN/Inf及精度问题；[]byte场景优先用ParseBytes和Append以减少内存分配。
字符串转数字必须检查 err，否则会静默出错
Go 的 strconv 所有解析函数（ParseInt、ParseFloat、ParseBool、Atoi）都返回 (value, error)，而 error 为 nil 才代表转换成功。不检查 err 是最常见也最危险的错误——比如 Atoi("abc") 返回 0 和 "strconv.Atoi: parsing \"abc\": invalid syntax"，但若直接用那个 0，业务逻辑就跑偏了。
-
" 123"（带空格）、"12.3"（含小数点）、""（空串）、"0x1F"（带前缀）都会失败，不是“尽力而为”，而是严格拒绝 - 需要容忍空格？先用
strings.TrimSpace预处理 - 想把浮点字符串转整？不能硬套
Atoi，得先ParseFloat再手动截断+范围校验
Atoi 和 ParseInt 到底该用哪个？
Atoi 只是 ParseInt(s, 10, 0) 的快捷封装，只支持十进制 int 类型；而 ParseInt 才是真正可控的底层接口。选错会导致编译失败或运行时溢出。
- 变量是
int32或int64？别用Atoi—— 它只接受string，只返回int，类型不匹配会编译报错 - 要解析十六进制（如
"FF"）、二进制（"1010"）或八进制？必须用ParseInt(s, base, bitSize)，base设为16、2、8 -
bitSize必须显式指定：想得int64就写64，想得 Go 默认int？没有“自动适配”——稳妥做法是统一用64，再转int（但要注意溢出）
浮点数转换藏着精度和特殊值陷阱
ParseFloat 和 FormatFloat 看似简单，但 IEEE 754 表示导致很多隐性问题：小数无法精确存储（如 0.1）、大整数超过 2^53 后丢失精度、输入 "NaN" 或 "Inf" 会成功返回却可能引发后续 panic。
-
ParseFloat("0.1", 64)返回的不是数学意义上的 0.1，而是最接近的float64近似值；比较时别用==，改用误差范围 - 输入是
"NaN"、"Inf"、"-Inf"时，err == nil，但结果不是普通数值——业务代码需调用math.IsNaN或math.IsInf主动过滤 -
FormatFloat(f, 'g', -1, 64)中的-1表示“尽可能短”，但对1e-5这类值可能输出科学计数法，若 UI 要求固定小数位，请用'f'并明确设prec
字节切片（[]byte）场景下优先用 Append* 和 Parse*Bytes
高频字符串/数字互转（如日志解析、协议编解码）中，反复分配 string 会触发 GC 压力。strconv 提供了面向 []byte 的变体，能复用底层数组，显著减少内存分配。
立即学习“go语言免费学习笔记（深入）”；
- 已有
[]byte数据？用ParseInt([]byte("123"), 10, 64)替代ParseInt(string(b), ...)，避免构造临时string - 批量拼接数字？用
AppendInt(dst, i, 10)，它把结果追加到dst切片里，可复用缓冲区；比多次Itoa+append([]byte{}, ...)更高效 - 注意：
Append*函数不返回新切片，而是返回扩容后的[]byte，务必接收返回值，否则可能覆盖原数据
真正难的从来不是“怎么写”，而是“什么情况下不该用”。比如 Atoi 看似省事，但一旦需求从“十进制整数”变成“支持十六进制 ID”，就得全量替换；又比如忽略 ParseFloat 返回的 NaN，可能让下游除零 panic 却查不出源头——这些边界，恰恰是线上事故最常藏身的地方。
