strconv.atoi 从不 panic，真实原因是忽略其 error 返回值导致逻辑错误；parsefloat 的 bitsize 参数指定浮点类型而非小数位数；字符串转 []byte 应直接用 []byte(s)；数值转字符串优先用 strconv 而非 fmt.sprint。
strconv.Atoi 转整数时 panic 的真实原因
不是 strconv.Atoi 本身 panic，而是你没检查它的第二个返回值 error。它从不 panic，但很多人直接忽略错误，导致后续用 0 当有效数字处理，逻辑出错。
- 常见错误现象：
strconv.Atoi("abc")返回0, error，若直接赋值给 int 变量并参与计算，结果完全偏离预期 - 正确姿势：必须用两个变量接收，且
if err != nil分支不能省略 - 注意：它只解析十进制整数，
"0x10"、"1e2"都会报strconv.ParseInt: parsing "xxx": invalid syntax - 性能影响极小，但频繁忽略错误会掩盖数据格式问题，线上排查成本远高于加一行 if 判断
strconv.ParseFloat 处理小数精度的坑
strconv.ParseFloat 的第二个参数是 bitSize（32 或 64），不是“保留几位小数”——这是最常被误解的一点。
- 常见错误现象：传
2期望得到两位小数，结果编译失败或数值异常；实际该参数决定 float32 还是 float64 类型 - 使用场景：读配置文件、解析 API 返回的 JSON 数值字段时，务必根据业务精度需求选 64（推荐）或 32
- 参数差异：
strconv.ParseFloat("1.23456789", 64)得到 float64；strconv.ParseFloat("1.23456789", 32)先转 float32 再转 float64，可能丢失末位精度 - 兼容性提示：Go 1.22+ 对超长浮点字符串解析更严格，
"1.23e"这类非法格式现在明确报错，旧版本可能静默截断
字符串 → 字节数组别硬套 strconv，用 []byte 更直接
strconv 包里没有把字符串转 []byte 的函数——它只管「字符串和基础数值类型」之间的转换。想转字节切片，别绕路。
- 常见错误现象：有人用
strconv.FormatUint(uint64(len(s)), 10)想“转字节”，结果得到的是长度的字符串，不是字节内容 - 正确做法：
[]byte(s)直接转换，零拷贝（底层共享底层数组），高效且语义清晰 - 注意：如果原字符串含 Unicode，
[]byte(s)得到的是 UTF-8 编码字节，不是 rune 列表；要遍历字符请用for _, r := range s - 性能对比：比任何
strconv中转方式快一个数量级，且无内存分配
数值 → 字符串时，fmt.Sprint 不如 strconv 更可控
fmt.Sprint 看似方便，但它会引入空格、换行、类型前缀等不可控输出；而 strconv 系列函数输出严格、无副作用，适合序列化、拼接路径、生成键名等场景。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
fmt.Sprint(123)在某些上下文中意外带空格（比如和结构体混用），或fmt.Sprint(float64(1.0))输出"1"还是"1.0"不确定 - 实操建议：整数用
strconv.Itoa（最快）、strconv.FormatInt(i, 10)（支持进制）；浮点用strconv.FormatFloat(f, 'g', -1, 64)（推荐 'g' 格式，自动省略尾随零） - 兼容性提醒：
'f'和'e'格式需显式指定精度，-1表示“尽可能短”，避免科学计数法干扰日志可读性 - 容易被忽略的点：
strconv.FormatBool比fmt.Sprintf("%t", b)快且无格式化开销，布尔值转换别漏掉它
真正难的不是记函数名，是每次调用前下意识问一句：这个字符串到底是不是我预期的格式？错误分支有没有真实处理？
