Go bytes.Buffer.Available 怎么判断可写空间：Grow、Append 与 ErrTooLarge 边界

拼接一段响应正文时，很多 Go 代码会反复调用 bytes.Buffer.WriteString，直到线上出现分配次数偏高，才开始关注“这个 buffer 现在还剩多少空间”。bytes.Buffer.Available 能回答当前还能直接写入多少字节，但它只描述现有尾部空间，不等于总容量，也不能代替对最终长度的估算。

先把 Available 读成“当前可写尾部”

bytes.Buffer 维护的是一段已经写入的数据和一段可继续使用的底层空间。下面这个例子中，缓冲区里已经有 5 个字节；Available 报告的是尾部还能直接写入的数量，而不是这块内存从头到尾的总大小。

package main

import (
    "bytes"
    "fmt"
)

func main() {
    var buf bytes.Buffer
    buf.WriteString("hello")

    fmt.Println("len:", buf.Len())
    fmt.Println("cap:", buf.Cap())
    fmt.Println("available:", buf.Available())
}

这三个值分别回答三个问题：已经写了多少、底层缓冲区总共能承载多少、当前位置后面还能不用扩容写多少。读取操作会改变读位置，因此消费掉前缀后，Len 和 Available 的关系也会随之变化。

Len、Cap、Available 该怎么放进判断表

不要写成“Available() >= n 就一定能完成整个拼接”。这只对下一次直接写入的长度成立；后续如果继续追加，仍然要重新判断。更稳的做法是先算出本轮的总长度，能估算时直接调用一次 Grow。

知道输出大小时，先 Grow 再写入

假设接口固定输出请求 ID、状态和一段消息，业务代码可以先估算总字节数，再让 buffer 一次性准备空间。Grow 只负责容量规划，不会改变 Len，所以调用之后仍要通过写入方法提交数据。

func buildReply(requestID, message string) []byte {
    var buf bytes.Buffer
    need := len("request_id=") + len(requestID) +
        len("&status=ok&message=") + len(message)
    buf.Grow(need)

    buf.WriteString("request_id=")
    buf.WriteString(requestID)
    buf.WriteString("&status=ok&message=")
    buf.WriteString(message)
    return buf.Bytes()
}

预留空间不是越大越好。若消息通常只有几百字节，却按 1 MB 固定增长，单次请求的内存峰值会被无意义地抬高。可以用实际样本估算，或者只对明显的大批量拼接路径做预留。

AvailableBuffer 和 Append 是一对提交协议

需要把数据填入 buffer 的尾部时，可以取出 AvailableBuffer() 返回的切片。它类似“暂存区”：你把字节写进切片，并不会自动增加 buffer 的长度；必须把填充结果交给 Append，buffer 才知道新增了多少字节。

func appendStatus(buf *bytes.Buffer, code int) {
    tail := buf.AvailableBuffer()
    tail = strconv.AppendInt(tail, int64(code), 10)
    buf.Append(tail)
}

func makeLine() string {
    var buf bytes.Buffer
    buf.WriteString("status=")
    appendStatus(&buf, 200)
    return buf.String()
}

这段写法的重点不是“少写一次临时切片”，而是清楚区分了借出的可写尾部和已经提交的 buffer 内容。如果只修改 tail 而忘记调用 Append，Len 不会增加，后续读取也看不到这段数字。

扩容和错误边界要单独验收

Grow 的参数来自请求或配置时，不能把它当作普通的加法。负数增长会触发 panic；当请求声明了一个不合理的大长度时，底层分配也可能失败。入口处应该先做业务范围限制，再让 buffer 承担正常的扩容。

func reserve(buf *bytes.Buffer, extra int) error {
    const maxExtra = 1  maxExtra {
        return fmt.Errorf("extra size out of range: %d", extra)
    }
    buf.Grow(extra)
    return nil
}

如果业务层把外部的 Content-Length、批量条数或压缩后长度直接换算成 Grow 参数，先限制单次响应大小，再记录被拒绝的输入。这样既防止异常请求把内存预算打穿，也能在日志里区分“业务上限拒绝”和“运行时分配失败”。

用小测试确认数据生命周期

最值得写的不是一个固定容量断言，而是对“写入、借出、提交、读取”这条数据链做验收。下面的测试覆盖空 buffer、提交前长度不变、提交后内容可读，以及追加不会破坏已有内容。

func TestAvailableBufferMustBeAppended(t *testing.T) {
    var buf bytes.Buffer
    if buf.Len() != 0 {
        t.Fatal("new buffer should be empty")
    }

    tail := buf.AvailableBuffer()
    tail = append(tail, 'o', 'k')
    if buf.Len() != 0 {
        t.Fatal("writing the borrowed tail must not commit length")
    }

    buf.Append(tail)
    if got := buf.String(); got != "ok" {
        t.Fatalf("got %q, want %q", got, "ok")
    }
}

再补一组容量观察测试：先调用 Grow(64)，确认 Cap 至少覆盖请求的预留值；对最终字节数的判断仍然使用 Len，不要把容量当成输出长度。性能基准则关注 allocs/op 和响应大小分布，单次样本不能代表所有请求。

常见问题

Available 和 Cap 有什么区别？

Cap 是底层 buffer 的总容量，Available 是当前位置后还能直接写的尾部空间。消费过前缀后，两者的差值关系会随内部读写位置变化。

调用 Grow 后 Len 会不会变大？

不会。Grow 只预留容量，只有 Write、Append 等写入动作才会增加 Len。

AvailableBuffer 写入后为什么读不到？

因为拿到的切片只是可写尾部，修改它不会自动提交长度。需要把最终切片传给同一个 buffer 的 Append。

Grow 失败会返回 error 吗？

Grow 没有 error 返回值。负数和过大增长可能触发 panic，所以外部长度必须先在业务边界做范围校验。

把容量判断放回数据流里

bytes.Buffer 的几个方法各自只负责一小段生命周期：Len 看已提交数据，Cap 看总容量，Available 看当前尾部空间，AvailableBuffer 借出可写区域，Append 负责把这次填充正式提交。把它们按这个顺序使用，再配合输入上限和小边界测试，才是真正可控的 buffer 优化。