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