Go bytes.Buffer Cap 和 Len 有什么区别

在 Go 的 bytes.Buffer 里，Len() 和 Cap() 观察的是两件不同的事：Len() 表示当前还能读出的未读字节数，Cap() 表示底层字节切片已经分配的总容量。前者回答“现在有多少内容”，后者回答“这块存储最多能承载多大空间”。

Cap 与 Len 分别在测量什么

bytes.Buffer 内部维护一段字节存储和一个“当前未读位置”。Len() 返回未读区域的长度；如果已经读走一部分，它只统计剩余部分。Cap() 则返回底层字节切片的容量，也就是这块存储已经申请的总空间。

用写入和读取观察两者变化

下面的示例先写入一段文本，再读取前两个字节。为了让观察结果稳定，使用 Grow(32) 先预留容量；具体容量值由实现的增长策略决定，所以示例只比较变化方向，不把某个具体数字当成跨版本保证。

package main

import (
	"bytes"
	"fmt"
)

func main() {
	var buf bytes.Buffer
	buf.Grow(32) // 先预留底层空间，便于区分“容量”与“已写入长度”。
	fmt.Printf("初始: Len=%d Cap=%d\n", buf.Len(), buf.Cap())

	_, _ = buf.WriteString("gopher") // 写入 6 个字节；写入失败时接口会返回错误，生产代码应保留检查。
	fmt.Printf("写入后: Len=%d Cap=%d\n", buf.Len(), buf.Cap())

	read := make([]byte, 2)
	if _, err := buf.Read(read); err != nil {
		fmt.Println("读取失败:", err) // 读取失败时不要把未读长度当成有效结果继续处理。
		return
	}
	fmt.Printf("读取 %q 后: Len=%d Cap=%d\n", read, buf.Len(), buf.Cap())
}

写入后，Len() 随内容增加；读取成功后，Len() 减少，因为未读区域缩短。只要缓冲区没有因为后续写入而重新分配，Cap() 通常保持原来的底层容量。最重要的判断是：Cap()-Len() 不是“还能读多少”，它混合了已读位置、未读数据和底层存储的实现细节。

预分配时为什么会出现 Cap 大于 Len

Grow(n) 的作用是保证后面至少有空间写入 n 个字节；它只扩张容量，不会凭空增加可读内容。因此调用 Grow(32) 后，Len() 仍然是零，而 Cap() 至少足以容纳这次增长请求。

func buildMessage(parts []string) string {
	var buf bytes.Buffer
	buf.Grow(64) // 预留大致规模；这是容量提示，不是消息长度的修改。
	for _, part := range parts {
		if _, err := buf.WriteString(part); err != nil {
			return "" // bytes.Buffer 的写入通常返回 nil，但保留错误分支更容易替换底层 Writer。
		}
	}
	return buf.String() // String 读取当前未读区域，不会把 Cap 当作有效文本。
}

预分配适合能估计输出规模的场景，例如拼接一条结构化日志或组装一次响应。它的收益是减少增长过程中的重复分配；它不改变 Len() 的语义，也不意味着缓冲区已经填满。

读取完再 Reset，为什么 Len 归零而 Cap 还在

Reset() 会清空缓冲区的逻辑内容，把 Len() 变成零，但会保留底层存储，以便下一轮写入复用。直接把“Len()==0”理解成“已经释放了所有内存”是不准确的；如果不再需要这块大容量缓冲区，应让它失去引用，或重新赋予一个新的小缓冲区。

func reuse(buf *bytes.Buffer, payload []byte) error {
	buf.Reset() // 清空上一轮内容，但保留已有容量，适合重复处理相近规模的任务。
	if _, err := buf.Write(payload); err != nil {
		return err // 把写入错误交给调用方，不用 Len 的变化猜测是否成功。
	}
	return nil
}

复用要有边界：如果某次请求写入了特别大的内容，之后长期复用同一个 Buffer，保留的大容量可能让常驻内存升高。此时可以按业务阈值决定丢弃过大的 Buffer，而不是把 Cap() 当作可读数据量。

排查 Cap 和 Len 混用的三个症状

1. 把 Cap 当作消息长度：序列化或发送前应使用 Len() 或 Bytes() 的未读区域，不能把底层未使用空间也发出去。
2. 用 Cap 判断是否有数据：预分配后的空 Buffer 可能 Cap() 很大，但 Len() 仍为零；有无数据应看 Len() > 0。
3. 用 Len 判断内存占用：读空或 Reset 后 Len() 为零，不代表底层容量也归零；需要观察复用规模时才看 Cap()。

如果任务要求知道“当前能读多少”，看 Len()；如果任务要求知道“缓冲区曾经或计划承载多大存储”，看 Cap()。两者同时记录，才能解释为什么内容已经清空，进程的缓冲对象仍然保留一块空间。

相关问题

Cap 一定比 Len 大吗？

对正常的 bytes.Buffer 状态，底层容量至少能覆盖当前数据，因此通常满足 Cap() >= Len()。但不要据此推导“剩余可读量”或增长策略。

读取一部分后 Cap 会立刻减少吗？

不会把读取动作理解成缩容操作。读取主要推进未读位置，底层存储通常继续保留；当缓冲区被读空时，Buffer 会重置内部状态以回收可复用空间，但不会把 Len() 的零值解释为没有容量。

什么时候应该丢弃而不是 Reset？

当 Cap() 远大于日常负载，且对象会长时间存活时，可以按业务阈值丢弃旧 Buffer，避免一次异常大输入变成长期内存占用。正常规模的重复任务则适合使用 Reset() 复用。