Go bytes.Buffer.Available 怎么判断写入余量：容量增长、短写与扩容验收

做日志拼接或协议编码时，先看一眼 bytes.Buffer.Available() 很有用，但它不是“这次写入一定不会扩容”的承诺。它返回的是底层缓冲区当前尚未使用的字节数；如果还要把数字直接追加进去，应把 AvailableBuffer() 返回的切片交给 append，再紧接着调用 Write。

Available 适合做容量观察和验收，AvailableBuffer 适合做一次追加式编码；真正判断是否扩容，要在写入前后结合 Cap、Len 检查。

先分清 Len、Cap 和 Available 各自回答什么

bytes.Buffer 同时承担读和写，最容易混淆的是“已经有多少数据”和“还能放多少数据”。Len 是当前未读数据长度，Cap 是底层字节切片的总容量，而 Available 是当前可以继续写入的空间。

用 AvailableBuffer 完成一次低分配追加

下面这个例子把整数追加到缓冲区。每轮先取得 AvailableBuffer，再用 append 写入临时切片，最后马上调用 Write。这个切片只在下一次修改 bytes.Buffer 前有效。

var buf bytes.Buffer
buf.Grow(32)
part := buf.AvailableBuffer()
part = strconv.AppendInt(part, 42, 10)
part = append(part, ':', 'o', 'k')
n, err := buf.Write(part)
fmt.Printf("written=%d err=%v len=%d cap=%d available=%d value=%q\n", n, err, buf.Len(), buf.Cap(), buf.Available(), buf.String())

预期能看到 value="42:ok"，并且 Len 增加了 5。Available 不等于结果长度，它只是写入后剩下的空间。

用 Cap 和 Len 验证到底有没有扩容

容量观察应该放在写入前后。保存写入前的 Cap 和 Len；如果写入后 Cap 变大，说明这次操作触发了扩容。Write 的返回值负责确认实际写入了多少字节。

beforeCap := buf.Cap()
beforeLen := buf.Len()
part := buf.AvailableBuffer()
part = append(part, "payload"...)
n, err := buf.Write(part)
expanded := buf.Cap() > beforeCap
fmt.Printf("beforeLen=%d afterLen=%d written=%d expanded=%t err=%v\n", beforeLen, buf.Len(), n, expanded, err)

如果预留空间足够，expanded 应为 false；如果追加数据超过当前余量，Cap 会增长，Available 也会按新的底层空间重新计算。

短写和切片失效是两个常见坑

不要保存 AvailableBuffer 跨过下一次写入

AvailableBuffer 返回的切片是给紧接着的一次 Write 准备的。调用 Write、Reset 或其他修改缓冲区的方法后，旧切片不能继续当作稳定存储使用。

不要只用 Len 推断 Write 是否成功

始终检查 n 和 err。标准 bytes.Buffer 通常返回全部长度和空错误，但调用链换成别的 io.Writer 后，短写可能出现。

相关问题

Available 是剩余可读长度吗？

不是。剩余可读数据看 Len，Available 看底层空间中尚未使用的部分。

AvailableBuffer 能直接修改 Buffer 吗？

不能。它返回供追加的切片，必须把追加后的切片紧接着传给 Write。

怎样确认一次追加触发了扩容？

保存写入前的 Cap，写入后比较 buf.Cap() > beforeCap，同时核对 Write 返回值和错误。

小结

把 Available 当作观察值，把 AvailableBuffer 当作一次性追加入口，再用 Len、Cap 和 Write 的返回值做验收，容量、数据和错误就不会混在一起。项目需要兼容 Go 1.20 或更早版本时，不能直接调用这两个 Go 1.21 新增方法。