Go bytes.Buffer AvailableBuffer 怎样复用临时缓冲区

如果一段 Go 代码要在循环里不断拼接数字、分隔符和短文本，最容易写成每轮先创建一个临时切片，再调用 bytes.Buffer.Write。Go 1.21 起，bytes.Buffer 提供了 AvailableBuffer，可以把当前尚未使用的容量借给一次紧接着的格式化操作，再交回同一个 Buffer 写入。

官方地址：https://pkg.go.dev/bytes#Buffer.AvailableBuffer

最小用法是：先调用 b.AvailableBuffer()，用 append 或 strconv.AppendInt 填充，随后立刻把结果传给同一个 b.Write。返回切片只适合这一次提交，不能跨越下一次 Buffer 写入继续保存或修改。

AvailableBuffer 到底复用了什么

AvailableBuffer 返回的是一个长度为 0、容量等于当前 b.Available() 的字节切片。它没有凭空创建一块新的业务缓冲区，而是把 Buffer 当前仍可使用的尾部空间暴露给下一次追加。官方文档把它定位为“追加后传给紧接着的 Buffer.Write”。

可以把几个量放在一起理解：

最小写法：追加后马上 Write

数字格式化可以直接使用 strconv.AppendInt，避免先把整数转成字符串再复制到另一个切片。注意，append 的返回值必须接住，因为当可用容量不足时，它可能返回一块新的底层数组。

package main

import (
    "bytes"
    "fmt"
    "strconv"
)

func main() {
    var b bytes.Buffer
    b.Grow(64) // 预留一小段容量，让短记录优先复用 Buffer 的尾部空间

    for i := int64(1); i 

这里的关键不是“先拿到一块永远有效的工作区”，而是把一次小记录的组装动作压缩在 AvailableBuffer → append → Write 这一小段里。Write 成功后，下一轮重新调用 AvailableBuffer，不要继续持有上一轮的 part。

和普通 Write、strings.Builder 怎么选

三个方案都能完成拼接，但优化目标不同。AvailableBuffer 适合“最终结果就是一个 bytes.Buffer，每次只追加一小段可计算内容”的场景。

不要为了“看起来更底层”强行改造所有 WriteString。如果每轮数据本来就是字符串，普通的 WriteString 通常更直观；只有在追加动作本身需要连续构造字节字段时，AvailableBuffer 才更有针对性。

两个容易踩到的生命周期边界

第一，返回切片的有效期很短。官方文档明确限定到 Buffer 的下一次写入操作；工程上可以把它理解成“本次提交的临时视图”，不要把它存入结构体、异步任务或跨函数长期缓存。

第二，追加后的切片必须传给 同一个 Buffer 的下一次 Write。如果中间先对 Buffer 调用了别的写入方法，或者把切片传给另一个 Buffer，代码就不再符合这个 API 的使用契约。需要保留独立结果时，应复制一份，而不是依赖这块临时空间。

func appendPair(b *bytes.Buffer, key string, value int64) {
    part := b.AvailableBuffer()
    part = append(part, key...) // 只构造当前这一对字段
    part = append(part, '=')
    part = strconv.AppendInt(part, value, 10)
    part = append(part, '\n')

    // 不要把 part 留给异步任务；提交后下一次写入就可能改变它的含义。
    if _, err := b.Write(part); err != nil {
        panic(err)
    }
}

版本和容量怎么处理

AvailableBuffer 在官方文档中标注为 Go 1.21.0 新增。如果项目还要支持更早的 Go 版本，不能直接调用它；可以继续使用预分配切片、Buffer.Write 或兼容版本的普通拼接方式。不要只因为本地开发环境较新，就把最低版本声明留在旧值上。

容量也不是越大越好。Grow 适合在能估算输出规模时提前预留；无法估算时让 Buffer 按需增长即可。预留太大，会让短请求长期持有不必要的空间；完全不预留，则可能在多轮追加时发生更多增长。应根据记录长度和对象复用周期做取舍。

如果 Buffer 只在一个函数里临时使用，优先保持代码清晰；如果它位于高频格式化路径，再考虑配合容量规划和基准测试观察分配变化。文章中的说明图只解释 API 关系，不代表某个机器上的性能结果。

速查结论

• AvailableBuffer 返回长度为 0、容量来自当前 Buffer 可用空间的切片。
• 用 append、strconv.AppendInt 等完成当前片段后，立刻传给同一个 Buffer 的 Write。
• 不要跨越下一次写入保存或修改返回切片；需要长期保存就复制。
• 最终只要字符串时优先比较 strings.Builder；已有完整字节片段时直接 Write。
• Go 1.21 之前的项目要使用兼容写法，不能直接依赖这个方法。

相关问题

AvailableBuffer 会自动把 append 的内容放进 Buffer 吗？

不会。它只是返回可追加的空切片，追加后仍要调用同一个 Buffer 的 Write 才会成为 Buffer 的有效内容。

返回切片能不能在 Write 之后继续使用？

不建议。下一次写入后它就超出文档承诺的有效边界；如果需要独立数据，应复制到自己的切片。

AvailableBuffer 一定比 WriteString 快吗？

不能这样下结论。它们解决的输入形态不同，是否减少分配还取决于数据类型、容量、调用频率和版本，应该用贴近业务的基准测试比较。