Go bytes.Buffer.AvailableBuffer 取出的切片什么时候才有效：Append 与 Commit 边界

把多条日志拼成一段响应体时，很多人会把 bytes.Buffer.AvailableBuffer() 当成“从 Buffer 借出来、以后随便保存”的切片。它的用途其实窄得多：先在这块可用容量上 append，紧接着把结果交给同一个 Buffer 的 Write；Buffer 下一次写入后，之前拿到的工作切片就不再可靠。

AvailableBuffer 适合“追加一小段数据，再立即 Write 提交”的循环，不适合跨轮次缓存、异步传递或在下一次写入后继续读取。

先看清 AvailableBuffer 的提交链

官方文档把这个方法描述成一个配合 Buffer.Write 使用的临时入口。它返回的是空切片，不是已经写入 Buffer 的数据。真正改变 Buffer 长度的是最后那次 Write。

package main

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

func main() {
    var buf bytes.Buffer

    part := buf.AvailableBuffer()
    part = strconv.AppendInt(part, 42, 10)
    part = append(part, ' ', 'O', 'K')
    _, _ = buf.Write(part)

    fmt.Printf("len=%d text=%q\n", buf.Len(), buf.String())
}

这段程序的关键顺序只有三步：AvailableBuffer 提供容量，append 生成要提交的内容，Write 把这段内容纳入 Buffer。运行结果应是 len=5 text="42 OK"。如果只做前两步而不调用 Write，buf.Len() 仍然是 0。

为什么 append 的返回值不能丢

切片的长度和容量是两个不同概念。AvailableBuffer 返回的切片长度为 0，所以它可以从容量尾部开始追加；但 append 可能返回一个新的切片头，尤其是在容量不足、或者你对它做了额外追加时。正确写法始终是接住返回值：

part := buf.AvailableBuffer()
part = append(part, "request_id="...)
part = append(part, requestID...)
_, _ = buf.Write(part)

这里的 part 是“准备提交的数据”，不是 Buffer 当前长度的别名。只有 Write(part) 执行后，buf.Bytes() 才能看到这次追加的内容。写入返回值也应该检查；对 bytes.Buffer 来说，正常情况下错误为 nil，但保留检查能让这段代码替换为其他 io.Writer 时不至于悄悄吞错。

下一次写入后，旧切片为什么不能继续依赖

官方文档明确限制了有效期：工作切片只到 Buffer 的下一次写入。下面这个反例的问题不在于切片一定马上显示乱码，而在于它把一个短生命周期的内部空间误当成了稳定快照。

var buf bytes.Buffer

first := buf.AvailableBuffer()
first = append(first, "first"...)
_, _ = buf.Write(first)

second := buf.AvailableBuffer()
second = append(second, "second"...)
_, _ = buf.Write(second)

// first 不应在这里继续作为长期数据使用。
fmt.Println(string(first))

第二次 Write 已经改变了 Buffer。此时继续依赖 first 的内容或底层存储，就是把实现细节当成 API 保证。若数据要交给异步 goroutine、放入缓存，或者要在后续写入完成后做断言，应在边界处复制：

snapshot := append([]byte(nil), first...)
// 后续可以安全地保存 snapshot

AvailableBuffer 和 Bytes 应该怎么选

如果只是为了减少一次临时分配，使用 AvailableBuffer 很合适；如果调用链里存在异步发送、队列投递或长时间缓存，先复制通常更便宜，也更容易审查。性能优化的边界不是“少复制就一定更快”，而是不能让数据所有权变得含糊。

用一个小检查确认代码没有越过边界

可以把检查固定成三问：这次 append 的返回值有没有接住？有没有马上对同一个 Buffer 调用 Write？写入之后是否还保存着旧切片并跨越下一次 Buffer 修改？三问中最后一项如果为“是”，就把复制放在交给异步调用方之前。

本地验证时，重点看两类结果：提交前 buf.Len() 不因准备切片而增加；提交后长度才增加，并且 buf.Bytes() 与预期文本一致。不要用一次运行中“旧切片看起来没变”来证明它可以长期使用，那只是偶然的内存布局。

相关问题

AvailableBuffer 返回的切片为什么长度是 0？

它把可用空间作为容量交给后续 append，因此准备阶段不会提前改变 Buffer 的长度。

调用 append 后不 Write，Buffer 会自动变长吗？

不会。追加只改变返回切片的长度，必须把该切片传给紧接着的 Buffer.Write 才算提交。

需要保存 Bytes 的结果时怎么办？

把它复制成独立切片，例如 snapshot := bytes.Clone(buf.Bytes())，然后再进行后续 Buffer 操作。

结语

AvailableBuffer 的价值在于把“准备数据”和“提交到 Buffer”连成一个低开销的小步骤。记住它的临时性：追加后立即写入，下一次写入后不再依赖旧切片；一旦数据要跨越这个边界，就明确复制。