Go bytes.Buffer Grow 后为什么 Len 还是零

调用 bytes.Buffer.Grow 后再查看 Len() 仍然是 0，这是正常行为。Grow(n) 只负责为后续写入预留至少 n 字节的容量，不会把这些空间标记成缓冲区中的有效数据；Len() 统计的是当前未读内容的长度。真正调用 Write、WriteString 或 WriteByte 写入后，长度才会增加。

官方文档可参考：https://pkg.go.dev/bytes#Buffer.Grow。排查这类问题时，先同时打印 Len 和 Cap，通常可以马上看出是“容量已经预留但内容尚未写入”，还是写入后又被读取、重置了。

Grow 只扩容，为什么不会改变 Len

bytes.Buffer 可以把内部状态拆成两个问题：还有多少空间可以继续写，以及当前还有多少字节可以读。前者对应 Cap()，后者对应 Len()。Grow(n) 解决的是分配问题，保证后续写入 n 字节时不必因为空间不足再次分配；它不代表已经产生了 n 字节业务数据。

可以把它理解成仓库提前腾出了货架，但货架上还没有货。下面的代码中，调用 Grow(32) 后，容量通常不小于 32，而长度仍是 0：

package main

import (
	"bytes"
	"fmt"
)

func main() {
	var buf bytes.Buffer
	buf.Grow(32) // 只预留后续写入空间，不制造有效数据

	fmt.Println("len:", buf.Len()) // 未读内容长度仍为 0
	fmt.Println("cap:", buf.Cap()) // 可用容量至少满足 Grow 的要求
}

因此，不能用 Len() == 0 推断 Grow 失败，也不能用 Cap() 代替数据长度。容量的实际增长策略由标准库实现决定，代码只能依赖“至少能够容纳后续 n 字节”这一保证。

怎样写入数据让 Len 真正增加

预留空间之后，要通过缓冲区提供的写入方法追加数据。Write 返回写入字节数和错误，WriteString 适合直接追加字符串；这两个方法会同步更新缓冲区的有效长度。

package main

import (
	"bytes"
	"fmt"
)

func main() {
	var buf bytes.Buffer
	buf.Grow(32) // 先减少已知大小写入时的扩容机会

	n, err := buf.WriteString("go buffer") // 只有真正写入后 Len 才会增加
	if err != nil {
		panic(err) // bytes.Buffer 的 WriteString 当前不会返回非 nil 错误
	}

	fmt.Println("written:", n)
	fmt.Println("len:", buf.Len())   // 9，表示当前未读数据字节数
	fmt.Println("data:", buf.String()) // String 读取当前内容，不是读取 Cap 的空闲空间
}

这里的长度按字节计算，不按中文字符数计算。例如字符串中包含中文时，Len() 返回 UTF-8 编码所占的字节数。若业务需要字符数量，应先明确是在统计字节、Unicode 码点还是用户可见字符，不要把缓冲区长度当作字符长度。

用 Len、Cap 和 Bytes 判断当前状态

排查时建议把三种状态一起记录：

func describeBuffer(buf *bytes.Buffer) {
	data := buf.Bytes() // 返回未读区域，不包含仅由 Grow 预留的空闲容量
	fmt.Printf("len=%d cap=%d bytes=%d data=%q\n", buf.Len(), buf.Cap(), len(data), data)
}

func readOne(buf *bytes.Buffer) error {
	if buf.Len() == 0 {
		return errors.New("buffer 没有可读数据") // 先判断有效长度，避免把容量当成内容
	}

	_, err := buf.ReadByte() // 读取会消耗未读数据，使 Len 减少
	return err
}

Bytes() 返回的切片长度与 Len() 相等，但它与缓冲区内部存储存在别名关系，且只适合在下一次修改前使用。若要跨越后续写入、读取或重置保存数据，应复制一份，而不是把这个切片当作永久快照。

负数 Grow、Reset 和复用时要注意什么

Grow 的参数不能是负数；负数会触发 panic。容量不足时，标准库会尝试扩容，极端情况下无法分配也会 panic。正常工程代码应让容量估算来自可信边界，避免把外部输入直接转换成没有上限的预留值。

如果缓冲区要循环复用，Reset() 会丢弃当前未读内容，因此 Len() 回到 0；容量通常会保留，便于下一次写入继续使用已有空间：

func reuseBuffer(buf *bytes.Buffer, text string) {
	buf.Reset() // 清空有效内容，但保留缓冲区作为复用空间
	_, _ = buf.WriteString(text) // 示例中忽略不可发生的 Buffer 写入错误

	if buf.Len() != len(text) {
		panic("写入长度与预期不一致") // 用 Len 检查实际有效数据，不检查 Cap
	}
}

一句话排查结论

Grow 看的是容量，Len 看的是未读数据；Grow 后 Len 为 0 不代表失败，只有写入方法才会增加有效长度。

如果日志显示 Cap 已经变大但 Len 仍为 0，检查是否遗漏了写入调用；如果写入后长度又归零，检查是否调用了 Read、Next、Reset 或 Truncate。如果长度和预期不一致，再确认统计的是字节而不是字符。

相关问题

Grow 后可以直接通过下标给 Buffer 写数据吗？

不可以。Grow 只保证容量，不改变长度；应使用 Write、WriteString 等方法追加数据，不能把容量当成已经存在的切片长度。

为什么 Write 后 Len 变大但 Cap 没有同步增加？

只要现有容量足够，写入可以直接使用已分配空间，因此 Len 会增加而 Cap 保持不变。这正是 Grow 预留空间可以减少重复分配的场景。

Reset 后原来的 Bytes 切片还能继续使用吗？

不应继续把它当作稳定快照。Buffer 修改后，Bytes 返回的切片有效性边界结束；需要长期保存时请复制数据。