Go strconv.AppendInt 如何复用缓冲区：容量增长与切片别名

写日志或拼接协议字段时，很多 Go 代码会把整数先转成字符串，再和前后缀拼起来。strconv.AppendInt 提供了另一条路径：直接把数字追加到已有的 []byte，只要容量足够，就能继续复用原来的底层数组；容量不够时，它才会分配新的数组。真正容易踩坑的地方，是追加返回的新切片和原切片别名之间的关系。

AppendInt 是否复用内存，先看传入切片的 cap；调用后必须接住返回值，而共享同一底层数组的切片可能同时看到追加产生的覆盖。

先看一段最小追加代码

下面的例子预留了 16 字节容量。buf 当前只有两个字节，但 AppendInt 返回的新切片会把 2026 接在 go 后面。

package main

import (
    "fmt"
    "strconv"
)

func main() {
    buf := make([]byte, 2, 16)
    copy(buf, "go")
    buf = strconv.AppendInt(buf, 2026, 10)
    fmt.Printf("%s len=%d cap=%d\n", buf, len(buf), cap(buf))
}

输出中的文本是 go2026。注意赋值语句：AppendInt 可能返回一个长度更长、甚至指向新数组的切片，调用方应该使用这个返回值继续传递。

len 与 cap 决定追加后的内存路径

切片的 len 是当前可读写的元素范围，cap 是从切片起始位置到底层数组末端的可用容量。追加前可以把这两个值打印出来，追加后再打印一次，观察长度增长和容量变化。

func appendNumber(buf []byte, n int64) []byte {
    beforeLen, beforeCap := len(buf), cap(buf)
    buf = strconv.AppendInt(buf, n, 10)
    fmt.Printf("len %d -> %d, cap %d -> %d\n", beforeLen, len(buf), beforeCap, cap(buf))
    return buf
}

func main() {
    buf := appendNumber(make([]byte, 0, 8), 42)
    buf = appendNumber(buf, 987654321)
    fmt.Println(string(buf))
}

第一次追加通常能在容量 8 的数组内完成；第二次追加需要更多空间，返回切片可能已经换到了更大的底层数组。这里用“可能”更准确，因为具体扩容策略由运行时和标准库实现决定，业务代码不要依赖某个固定增长倍数。

为什么一定要接住 AppendInt 的返回值

切片值本身包含指针、长度和容量三个部分。函数拿到的是切片头的副本，因此函数内部即使改变了长度，也不会改变调用方变量的长度；返回值就是把新的切片头交还给调用方。

func main() {
    buf := make([]byte, 0, 8)
    strconv.AppendInt(buf, 7, 10) // 返回值被忽略
    fmt.Printf("len=%d, text=%q\n", len(buf), buf)

    buf = strconv.AppendInt(buf, 7, 10)
    fmt.Printf("len=%d, text=%q\n", len(buf), buf)
}

第一行仍然是 len=0，因为调用方的切片头没有更新。但底层数组在容量允许时可能已经被写入了字符 7；这正是“看不见的写入”，不要把它当成可用结果。只有第二次把返回值赋回 buf，长度才与内容一致。

别名切片会怎样看到追加结果

当一个切片被重新切出视图时，base 和 view 仍可能共享底层数组。下面的代码让 view 保留一部分容量，再从 base 追加一个数字；追加没有触发扩容时，view 的扩展范围可能读到刚写入的字节。

func main() {
    base := make([]byte, 2, 8)
    copy(base, "go")
    view := base[:2:8]

    base = strconv.AppendInt(base, 17, 10)
    fmt.Printf("base=%q view=%q\n", base, view[:len(base)])
}

这里的 view[:len(base)] 只是为了展示同一底层数组中新增的字节。生产代码不要依赖这种隐式可见性：如果一个切片要交给异步任务、缓存或下游模块，先用 slices.Clone 或 append([]byte(nil), src...) 做明确复制，再让两个模块分别管理自己的数据。

把追加封装成边界清楚的函数

在日志编码器、二进制协议或批量导出中，可以让函数明确返回新切片，不把底层数组所有权藏在全局变量里：

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

func main() {
    record := appendID(make([]byte, 0, 32), 1001)
    fmt.Println(string(record))
}

调用方只负责决定初始容量和最终去向，函数只负责把 id= 与数字追加进去。若返回结果要跨 goroutine 使用，仍应确认它不会和下一轮编码复用同一块数组；容量复用解决的是分配问题，不会自动解决并发所有权问题。

常见误区与检查顺序

• 把 len 当成可写总容量：追加能否复用要看 cap，当前可读范围仍由 len 决定。
• 忽略返回值后直接读取原切片：原切片长度没有变化，底层数组里偶然出现的字节不能算结果。
• 看到一次地址没变就写死扩容结论：不同输入长度和实现版本会改变是否扩容，代码应只依赖切片契约。
• 把复用缓冲区直接交给异步消费者：只要生产者继续追加，消费者就可能看到变化，必要时应复制。

相关问题

AppendInt 比 fmt.AppendInt 更适合什么场景？

当目标就是把整数追加进 []byte，strconv.AppendInt 的接口更直接；是否更快仍应以自己的数据规模和基准测试为准。

容量不足时 AppendInt 一定立刻分配吗？

如果现有容量放不下追加结果，就需要获得更大的底层存储；具体分配与扩容细节不应写成固定倍数承诺。

如何避免切片别名造成覆盖？

在边界处复制数据，例如使用 slices.Clone，并让接收方拥有独立的字节存储。

AppendInt 支持哪些进制？

第三个参数是进制，常用值为 10 和 16；传入的进制必须符合 strconv.AppendInt 的参数约束，格式需求复杂时应配套测试。

最后的判断

把整数追加到字节缓冲区时，先检查 len、cap 和切片所有权，再调用 AppendInt 并接住返回值。需要共享数据时明确复制，需要复用时只把它当作容量策略，而不是并发安全保证。