strconv.AppendInt 能省掉一次分配，因为它接收并原地追加到 []byte 切片，复用底层数组；而 fmt.Sprintf 或 strconv.Itoa 每次都新建字符串并分配内存。
为什么 strconv.AppendInt 能省掉一次分配？
直接用 fmt.Sprintf 或 strconv.Itoa 拼接整数，每次都会新建字符串——底层是新申请 []byte、拷贝、转成 string。而 strconv.AppendInt 接收一个 []byte，原地追加字节，返回扩容后的切片。只要调用方复用底层数组，就能避开每次分配。
strconv.AppendInt 的正确调用姿势
它不生成 string，只操作 []byte，所以你得自己管理缓冲区。常见错误是传入空切片 []byte{}——这看似方便，但每次都会触发扩容，失去复用意义。
- 预先估算长度：比如拼接 100 个 int64（最大 20 字节），可初始化
buf := make([]byte, 0, 2000) - 始终用返回值：
buf = strconv.AppendInt(buf, n, 10)，不能忽略返回值，因为底层数组可能已更换 - 转 string 时用
string(buf)，不是string(buf[:len(buf)])（后者冗余，buf本身就是当前有效切片）
和 bytes.Buffer 比谁更快？
在纯整数追加场景下，strconv.AppendInt + 复用 []byte 几乎总是更快：没有接口调用开销，没有锁，没有额外的字段维护。但 bytes.Buffer 更通用，支持任意类型写入。
- 如果你只追加整数（尤其循环内高频调用），优先选
strconv.AppendInt - 如果还要混写字符串、字节、其他类型，
bytes.Buffer更省心，性能差距通常可接受 - 注意：
bytes.Buffer的WriteString和Write仍会触发小分配；它的Grow可预分配，但不如手动make精确
容易被忽略的负数与进制陷阱
strconv.AppendInt 对负数处理正确，但进制参数写错会导致静默异常结果——比如把 10 写成 0，实际按 8 进制解析（Go 中 0 表示八进制），但函数不会报错，只会输出错误数值。
立即学习“go语言免费学习笔记（深入）”；
- 进制必须是 2、8、10 或 16；其他值 panic，但生产环境应避免依赖 panic 来校验
- 负数自动带
-前缀，无需额外判断；但如果你拼接的是无符号整数，别误传int64负值 - 示例：
buf = strconv.AppendInt(buf, -42, 10)→buf后追加"-42"；strconv.AppendInt(buf, 255, 16)→"ff"
缓冲区复用是否真正生效，取决于你有没有在循环外初始化并持续传递同一个切片变量——漏掉这点，所有优化都白做。
