优先用 strconv.itoa 转 int 类型整数，性能好且无分配；非 int 类型需用 strconv.formatint（int64）或 formatuint（uint64）；避免 fmt.sprintf 以防性能损耗；转回时注意 atoi 仅支持十进制，parseint 需显式处理前缀与空白。
直接用 strconv.Itoa 就行，但得知道它只处理 int
它是最常用、最轻量的整数转字符串方式，底层就是调用 strconv.FormatInt(int64(i), 10)，所以性能好、无分配（小整数场景下）。但注意：strconv.Itoa 参数类型固定是 int，不是任意整数类型。
常见错误现象：cannot use int64(42) as int value in argument to strconv.Itoa —— 这是因为你传了 int64、uint 或其他整型，Go 不做隐式转换。
- 如果变量是
int64、int32等，先显式转成int（仅当值在int范围内安全时） - 更稳妥的做法是用
strconv.FormatInt（配int64）或strconv.FormatUint（配uint64） - 别对负数做无符号转换，会溢出成巨大正数再转字符串，结果完全不对
strconv.FormatInt 和 strconv.FormatUint 怎么选
当你明确知道整数类型超出 int 范围（比如从 os.Stat().Size() 拿到的 int64），或者处理无符号数（如位掩码、哈希值），就得换函数。
使用场景举例：HTTP 响应头里写文件大小、日志中打印内存地址偏移、序列化协议字段。
立即学习“go语言免费学习笔记（深入）”；
-
strconv.FormatInt(i, 10)：i必须是int64，第二个参数是进制（10=十进制，2=二进制，16=十六进制） -
strconv.FormatUint(u, 16)：u必须是uint64；传uint32需先转uint64 - 进制填错会导致输出非预期格式，比如想转十进制却写了
16，255变成"ff"
为什么不用 fmt.Sprintf("%d", i)
它能兼容所有整数类型，写起来省心，但代价明显：每次调用都触发格式解析、反射检查类型、堆上分配字符串。压测下比 strconv.Itoa 慢 3–5 倍，GC 压力也高。
常见错误现象：在高频循环（如日志批量拼接、网络包编码）里用 fmt.Sprintf，CPU 和内存监控突然飙升。
- 仅在调试、低频、或需要复合格式（如
"id:%d,name:%s"）时用fmt.Sprintf - 纯整数转字符串，优先选
strconv系函数 - 如果真要拼接，考虑
strings.Builder+strconv方法，避免重复分配
字符串转回去时容易忽略的兼容性问题
很多人只关心“怎么转出来”，但后续常要转回整数——这时候 strconv.Atoi 和 strconv.ParseInt 的行为差异就暴露了。
错误现象：strconv.Atoi("0x2a") 报 invalid syntax，而你以为它支持十六进制前缀；或者 ParseInt(s, 10, 64) 在遇到空格或换行时静默失败。
-
strconv.Atoi只认十进制，不接受0x、0o、0b前缀，也不跳过前后空白 -
strconv.ParseInt(s, 0, 64)中进制设为0才自动识别前缀，但要求字符串严格匹配（如"0xFF"可，" 0xFF "不可） - 生产代码里建议统一用
ParseInt(s, 10, 64)并提前strings.TrimSpace，避免隐式失败
