Go strconv.AppendInt 替代 fmt.Sprintf 的性能收益：分配次数、可读性与基准边界

线上批量导出接口里，一行文本只有一个整数需要转成字符串，却因为顺手写了 fmt.Sprintf("%d", id) 让格式化路径承担了全部工作。只改成 strconv.AppendInt 并不等于所有代码都会变快：真正的收益取决于是否已有字节缓冲区、结果是否必须是 string，以及基准是否把转换之外的成本隔离出来。

单个整数转文本、调用频率高且允许围绕 []byte 组织数据时，优先测试 strconv.AppendInt；需要多类型、多占位符和直接得到字符串时，fmt.Sprintf 的可读性通常更值钱。

先让基准回答问题：fmt.Sprintf 和 strconv.AppendInt 到底差在哪里

fmt.Sprintf 属于 fmt 的 Sprint 家族，接收格式字符串和参数，直接返回一个 string。strconv.AppendInt 则把十进制或指定进制的整数追加到目标字节切片，并返回扩展后的切片。两者输出可以相同，但中间的数据路径不一样。

先写一个只测转换的基准。Sink 防止编译器把结果当成无用值删除：

package formatbench

import (
    "fmt"
    "strconv"
    "testing"
)

var Sink string
var SinkBytes []byte

func BenchmarkSprintf(b *testing.B) {
    for i := 0; i 

运行 go test -bench=. -benchmem 后，重点看每个基准的 ns/op、B/op 和 allocs/op。Go 的基准文档也强调，基准应当运行快、噪声可控，并且要能反复比较改动；所以这一步先不要把网络、JSON 编码和日志输出混进来。

为什么 AppendInt 经常少一次分配

fmt.Sprintf 需要解析格式串、处理参数接口并组装返回字符串；这个接口的优势是表达力强。AppendInt 把结果写入调用方提供的 dst，容量足够时可以沿用原底层数组。它不是“无条件零分配”：第一次扩容、后续把字节切片转成 string，都会改变结果。

下面的示例把整数追加到一行导出记录，追加动作和结果边界分开：

func appendRecord(dst []byte, id int64) []byte {
    dst = append(dst, "id="...)
    dst = strconv.AppendInt(dst, id, 10)
    dst = append(dst, '\n')
    return dst
}

func recordString(id int64) string {
    buf := make([]byte, 0, 24)
    buf = appendRecord(buf, id)
    return string(buf)
}

如果下游最终接受 []byte，可以继续追加，避免过早跨到 string 边界；如果 API 明确要求 string，转换仍然是合理的最后一步。不要为了追求一项分配数字，把本来清楚的接口改成到处传可变缓冲区。

把三个边界写进选择规则

这里最容易出错的是返回值：AppendInt 可能扩容，所以必须写成 dst = strconv.AppendInt(dst, id, 10)。只调用而不接收返回值，在容量不足时会把追加结果留在新切片里，调用方仍拿着旧的 dst。

常见问题

AppendInt 的 base 可以随便填吗？

不能。常用十进制传 10，十六进制传 16；应根据协议或展示约定选择，不能为了性能随意改进制。

把 fmt.Sprintf 全部替换成 AppendInt 会更好吗？

不一定。多占位符格式化、低频路径和强调可读性的代码，保留 fmt.Sprintf 更稳妥；先用基准确认热点。

为什么我的 allocs/op 没有下降？

检查基准是否每轮都重新创建缓冲区、是否在循环中做了 string(buf)，以及是否把扩容成本算进来了。还要确认比较的两段代码完成的是同一件事。

把验证结果留在代码旁边

这类替换的结论不应来自“某个函数听起来更底层”。保留两个基准、固定输入范围，运行 go test -benchmem，再结合真实调用链判断：如果输出仍要立刻转成 string，收益可能缩小；如果一批字段都能追加到同一个 dst，减少中间格式化对象才更有意义。