Go bytes.Buffer.Available 如何估算追加空间：Grow、容量与写入边界

给日志或协议帧追加内容时，bytes.Buffer 的 Cap() 不是“现在还能写多少”。真正表示未使用空间的是 Available()，它等于底层缓冲区容量减去当前已占用长度；如果预计追加量超过这个值，再调用 Grow 才能把分配动作提前。这个区别能避免把容量看大，或者为了一个小追加反复猜测是否会扩容。

Available() 只回答当前还剩多少未用容量；它不承诺下一次写入永远不分配。需要硬性预留空间时，用 Grow(n)，需要把预留空间直接拿来填充时，再考虑 AvailableBuffer()。

Available 先回答还能直接追加多少

先看一个最小现场。下面的 Len、Cap 和 Available 都是同一个 Buffer 的观察值，不是三个独立的预算。

var buf bytes.Buffer
buf.Grow(32)
buf.WriteString("go")

fmt.Println(buf.Len())       // 2
fmt.Println(buf.Cap())       // 至少 32
fmt.Println(buf.Available()) // Cap() - Len()

源码中的实现是 cap(b.buf) - len(b.buf)。所以这里的判断关系很直接：如果准备追加 10 个字节，先比较 10 ；如果不满足，就让 Grow(10) 负责扩容，而不是手动按 Cap() 猜剩余空间。

读过数据后，长度和容量要分开理解

Len() 表示未读部分的字节数。调用 Read 后，内部偏移会前移，未读长度可能下降，但底层存储仍可能保留。此时不要把“已经读走的字节”简单当成 Available() 的结果；Buffer 会在合适的写入路径里复用或整理空间，外部只应依赖公开方法的契约。

预计追加量超过 Available 时用 Grow

Grow(n) 的用途是提前保证空间，而不是把 Buffer 的长度直接增加 n。它不会凭空写入零字节，调用之后仍需由 Write、WriteString 等方法写入内容。

func appendFrame(buf *bytes.Buffer, payload []byte) {
    if len(payload) > buf.Available() {
        buf.Grow(len(payload))
    }
    _, _ = buf.Write(payload)
}

这里的边界有三个：Grow 的参数为负数会 panic；空间足够时它可以不重新分配；空间不足时它可能搬移已有数据或申请更大的底层切片。调用方不需要复制这套内部策略，只要在需要时预留、写入后再用 Len() 或返回值核对结果。

AvailableBuffer 适合“填满后立刻 Write”

如果代码本来就要把一段数据追加到 Buffer，可以使用 AvailableBuffer() 得到一个长度为 0、容量等于可用空间的切片，再扩展切片长度并填充。它的价值是让填充动作直接落在 Buffer 的预留区域附近，但使用顺序必须保持清楚。

var buf bytes.Buffer
buf.Grow(16)

dst := buf.AvailableBuffer()
dst = append(dst, 'o', 'k')
buf.Write(dst)

fmt.Println(buf.String()) // ok

AvailableBuffer() 返回的切片只在对 buf 的下一次写操作前有效。上面的 Write 完成后，不要继续拿旧的 dst 去推断下一轮可写区域；重新调用 AvailableBuffer()，或者直接使用普通的 Write。如果要开始下一轮复用，先对 Buffer 调用 Reset，再重新获取可用切片。

三个容易混淆的边界

Cap 够大不等于当前位置能连续写满

Cap() 是底层字节切片从起点看拥有的总容量，Available() 才是当前切片末端之后的空间。读写偏移、内部整理和后续扩容都由 Buffer 管理，业务代码不要根据一次打印结果保存永久的“可写指针”。

Grow 不改变 Len

如果调用 Grow(64) 后立刻读取 Len()，长度不会变成 64。只有真正写入后，长度才会上升；这也是验收预留是否生效时最容易写错的地方。

不要跨写操作复用 AvailableBuffer

同一个 Buffer 的下一次写可能改变底层切片。把 AvailableBuffer() 返回值放进结构体或异步任务，等很久后再写回，既不符合它的有效期，也会让代码很难判断数据是否仍指向当前存储。

用一个小检查确认空间判断

排查追加空间问题时，可以把预计写入量、写入前后的 Available() 和最终 Len() 一起打印。不要只盯着 Cap()，因为它无法说明当前末端还有多少空间。

func checkAppend(payload []byte) {
    var buf bytes.Buffer
    buf.Grow(8)
    before := buf.Available()

    if len(payload) > before {
        buf.Grow(len(payload))
    }
    _, _ = buf.Write(payload)
    fmt.Printf("want=%d before=%d after=%d len=%d\n",
        len(payload), before, buf.Available(), buf.Len())
}

可见的成功状态是：写入后 Len() 增加了实际字节数，Available() 不再大于写入前的可用空间（如果发生了 Grow，容量可能变大），并且输出内容与 payload 一致。这个检查足以覆盖大多数“Buffer 明明有 Cap 却仍扩容”的误判。

相关问答

Available() 会返回整个底层数组的剩余容量吗？

它返回当前 Buffer 内部切片长度之后的未用容量，按公开实现可理解为 Cap() - Len()；不要把它理解成已经读过区域的总和。

应该总是先 Grow 再 Write 吗？

不需要。只有当追加量已知、希望减少扩容不确定性，或者要使用 AvailableBuffer() 时才值得预留；普通小写入直接调用 Write 更简单。

AvailableBuffer 能不能保存到下一次请求继续用？

不能。它只适合在返回后立即填充，并紧接着对同一个 Buffer 做下一次写操作；跨请求或跨写操作应重新获取切片。

记住一条实用顺序：先用 Len、Cap、Available 看清当前状态，需要预留就 Grow，需要就地填充才使用 AvailableBuffer，最后用实际写入结果验收。