Go bytes.Buffer.Grow 怎么预留容量又避免误判当前长度

在 Go 里用 bytes.Buffer 拼接导出文本时，我最常见到的误判是：调用 Grow(1024) 后，直接把 Len() 当成已经有 1024 字节。实际上，Grow 只负责保证后续写入空间，Len 仍然只表示当前未读内容的字节数。

这篇只解决一个窄问题：如何用 Len、Cap 和 Grow 做容量预留与结果判断，不讨论 bytes.Buffer 的并发使用。

先把三个数字放回各自的位置

Len() 是当前缓冲区中“还没有被读走”的字节数；Cap() 是底层字节切片已经分配的总容量。Grow(n) 的语义是保证之后至少还能写入 n 个字节而不再次分配，它不会替你写入数据，因此不会让 Len() 增加。

例如下面的输出中，预留 64 字节以后，真正写入的只有 5 字节：

package main

import (
    "bytes"
    "fmt"
)

func main() {
    var b bytes.Buffer
    b.Grow(64) // 只预留后续写入空间，不填充 64 个零字节
    _, _ = b.WriteString("hello") // 写入后 Len 才会增加
    fmt.Printf("len=%d cap=%d\\n", b.Len(), b.Cap())
}

这里可以确定的是 len=5，而 cap 至少足以容纳这次预留和写入。容量的具体增长策略不是业务契约，不应把某个运行版本观察到的精确数字写死在判断里。

拼接前按“还要写多少”调用 Grow

实际工程里更有用的计算方式是：先估算接下来要追加的字节数，再调用一次 Grow。估算应使用字节长度，例如字符串用 len(s)，而不是把中文字符数当作字节数。

package main

import "bytes"

// buildLine 预留整行可能写入的字节数，避免把容量误当成内容。
func buildLine(prefix, value string) string {
    var b bytes.Buffer
    b.Grow(len(prefix) + len(value) + 1) // 加 1 给换行符，len(string) 按字节计
    _, _ = b.WriteString(prefix)         // Write 后 Len 才反映已写内容
    _, _ = b.WriteString(value)
    _ = b.WriteByte('\n') // WriteByte 的错误在 bytes.Buffer 中始终为 nil
    return b.String()
}

这个模式的收益是减少扩容路径，但它不是“精确控制最终容量”的接口。写入量估少了仍会自动增长，估多了则可能多占一些内存；预估成本很高时，宁可使用保守估计，也不要为了一个漂亮数字让代码变复杂。

复用 Buffer 时，Len 和容量要分别判断

如果只关心内容是否为空，用 Len() == 0；如果关心是否还有足够的底层空间，则看 Cap()，或者在当前 Go 版本中使用 Available() 表达剩余可写容量。不要用 Cap() == Len() 推断“已经写满”，因为读操作会改变未读长度，而底层容量仍可能保留。

func appendChunk(b *bytes.Buffer, chunk string) {
    if len(chunk) == 0 { // 空片段不会改变 Len，也无需预留
        return
    }
    if b.Available() 

Grow 接收负数会 panic；请求的容量无法分配时也会 panic。因此，传入它的差值必须来自可靠的非负长度计算，不要把可能溢出的业务数值直接转换成 int 后传入。

一个可执行的取舍结论

如果一次拼接的写入量大致可知，调用一次 Grow 是简单有效的预分配手段；如果写入量不可知，直接写入也能让 Buffer 按需增长，不必为了预估而引入额外状态。最终判断可以记成三句话：

• Len 回答“现在有多少未读内容”。
• Cap 回答“底层总共分配了多少空间”。
• Grow 回答“为后续至少多少字节提供不再次分配的保证”。

另外，bytes.Buffer 不是并发安全容器；这篇的容量优化不改变所有权和同步要求。

常见问题

调用 Grow 后为什么 String 还是空的？

因为 Grow 只预留空间，没有写入数据。只有 Write、WriteString 或 WriteByte 等操作成功后，Len 和 String 才会反映内容。

应该用 Cap 还是 Len 判断结果大小？

判断结果内容用 Len，判断底层容量用 Cap。两者服务不同问题，不能互相替代。