Go 怎样估算 bytes.Buffer 还能容纳多少数据

我在拼接响应体或批量生成日志时，最容易误判的不是 bytes.Buffer 能不能写，而是“现在还能直接写多少”。结论很简单：看当前追加空间用 Available()，看底层总容量用 Cap()，看未读内容用 Len()；如果已经知道下一次至少要追加多少字节，再用 Grow(n) 预留。

官方文档：https://pkg.go.dev/bytes#Buffer.Available

Available() 是当前没有被 Buffer 使用的追加空间，Cap() 是底层字节切片的总容量。容量估算只用于做写入决策，不能代替对输入大小、错误和业务上限的处理。

Len、Cap、Available 到底分别表示什么

Len() 返回缓冲区未读部分的字节数，Cap() 返回底层字节切片的总容量，Available() 返回当前还能在尾部直接追加的未使用空间。它们描述的是三个不同视角，不能只拿一个数替代另外两个。

尤其要注意，Cap() 不是“还能写多少”。一个 Buffer 可能已经写入了部分数据，但底层容量还没有用完；也可能读过一部分内容，Len() 下降了，却不能据此推出下一次写入一定可以使用同样大小的空间。真正面向追加的判断，直接调用 Available() 更稳妥。

用 Available 判断一次追加是否需要扩容

如果下一段数据的大小已经明确，可以把它和 Available() 比较。下面的示例只关注容量关系：有足够尾部空间就直接写，不足时用 Grow 先保证本次追加量。

package main

import (
	"bytes"
	"fmt"
)

func appendText(buf *bytes.Buffer, text string) {
	need := len(text)

	// Available 面向当前追加空间，不把 Cap 误当成剩余空间。
	if buf.Available() 

这里的 need 是字符串的字节数，不是字符数；中文文本用 UTF-8 编码时，一个字符可能占多个字节。容量判断只负责减少不必要的增长，不能保证输入一定适合内存，也不意味着整个追加过程具备原子性。

需要稳定追加量时用 Grow 预留

当调用方已经知道接下来要写入的字节数，Grow(n) 比“先猜一个较大的 Cap()”更直接。它表达的是一个明确承诺：从当前 Buffer 状态出发，后面至少有 n 字节可写而不再触发一次分配。

import "fmt"

func appendPayload(buf *bytes.Buffer, payload []byte) error {
	// 先用待追加字节数做容量准备，避免把总 Cap 当作可用量。
	if buf.Available() 

这个函数适合“下一块数据大小已知”的场景，例如拼接一个编码后的消息或一次性追加文件片段。若数据来自持续读取的流，单次大小并不确定，就不要把 Available() 当成固定窗口；让 Buffer 按需增长，或在业务层设置独立的最大长度更合适。

复用 Buffer 时，容量估算要和生命周期一起看

Reset() 会清空当前内容，但保留底层存储供后续写入使用。批量处理相似大小的数据时，可以在循环外创建 Buffer，每次开始前重置，再用 Available() 判断本轮追加空间。这样做的收益是复用已分配内存，代价是必须明确哪些字符串或字节视图仍然有效。

func buildLines(lines []string) string {
	var buf bytes.Buffer
	for _, line := range lines {
		// 每轮复用底层存储，避免上一轮内容残留。
		buf.Reset()
		buf.Grow(len(line) + 1)
		buf.WriteString(line)
		buf.WriteByte('\n')
	}
	return buf.String()
}

不要把 Cap() 当作业务限制，也不要因为 Available() 较大就无限接收外部输入。需要上限时，用累计字节数、请求体限制或分块策略单独控制。还要记住，bytes.Buffer 的这些方法描述的是一个 Buffer 实例的状态；并发读写时应由调用方提供同步边界。

速查结论与相关问题

Available 和 Cap-Len 是一回事吗？

不要把它们当作稳定等式。Cap() 描述底层总容量，Len() 描述未读内容，Buffer 还维护着内部读写位置；面向当前尾部追加时，以 Available() 的结果为准。

Grow(0) 能不能用来查询容量？

查询直接使用 Available() 或 Cap()。Grow 的职责是为确定的追加量预留空间，不应被当成容量查询接口。

什么时候不必提前调用 Grow？

当数据大小不确定、写入次数很少，或者提前估算本身比一次正常扩容更复杂时，可以直接写入。只有在追加量明确且分配成本值得控制时，预留才更有意义。