Go bytes.Buffer设置最大容量防止请求体膨胀的处理方案

先把结论说清楚：bytes.Buffer 没有“最大容量”配置项，Grow 只是提前申请一段容量，不能阻止后续 Write 继续扩容。要防止请求体把内存顶大，应在输入侧用 http.MaxBytesReader 限制读取，再用一个受限 io.Writer 包住 bytes.Buffer，这样超限时能返回明确错误，而不是等到分配失败才处理。

官方资料：https://pkg.go.dev/bytes　请求体限制：https://pkg.go.dev/net/http#MaxBytesReader

bytes.Buffer的Cap是容量观察值，不是写入上限

bytes.Buffer 的零值可以直接使用。Len() 返回尚未读取的字节数，Cap() 返回底层字节切片已经分配的总空间；调用 Grow(n) 后，只能保证接下来至少有 n 个字节的可写空间。官方文档没有提供 SetMaxCap 一类的方法，普通 Write 和 ReadFrom 仍会按需增长。

var buf bytes.Buffer
buf.Grow(64 * 1024) // 中文说明：为预计的小请求预留空间，不表示最多只能写 64 KiB。
_, _ = buf.Write(payload) // 中文说明：继续写入时，Buffer 仍可能自动扩容。
fmt.Println(buf.Len(), buf.Cap()) // 中文说明：Len 是数据长度，Cap 是已分配空间。

因此，单独写 buf.Grow(maxBody) 只是在“提前分配”和“减少扩容次数”之间做取舍。如果输入来自网络，真正要防的是读取循环不断追加数据；不能把 Cap() 当成拒绝条件，也不建议依赖 bytes.ErrTooLarge，因为那是内存无法分配时的 panic 路径，不是业务层的正常超限错误。

用受限Writer让每次写入都先检查上限

如果代码不只处理 HTTP，还要把文件、消息队列或压缩流写进同一个缓冲区，可以在 bytes.Buffer 外包一层小型 Writer。它不修改 Buffer 的内部行为，只在真正调用 Buffer.Write 前检查累计长度。检查失败时返回自定义错误，io.Copy、io.ReadAll 等上层函数就能沿着标准接口收口。

package upload

import (
    "bytes"
    "errors"
    "fmt"
    "io"
)

var ErrBodyTooLarge = errors.New("request body exceeds buffer limit")

type cappedBuffer struct {
    bytes.Buffer
    limit int64
}

func (b *cappedBuffer) Write(p []byte) (int, error) {
    // 先检查累计长度，超限时不把这一块交给 bytes.Buffer。
    if b.limit  b.limit-int64(len(p)) {
        return 0, ErrBodyTooLarge
    }
    // 只有通过边界检查后才允许底层 Buffer 扩容和写入。
    return b.Buffer.Write(p)
}

func readIntoBuffer(src io.Reader, limit int64) ([]byte, error) {
    b := &cappedBuffer{limit: limit}
    // io.Copy 会持续调用受限 Writer，错误会在超限处返回。
    if _, err := io.Copy(b, src); err != nil {
        return nil, fmt.Errorf("read body: %w", err)
    }
    return b.Bytes(), nil
}

这个包装器的关键是“拒绝整块写入”：如果剩余空间不足，就返回 ErrBodyTooLarge，不会把部分数据悄悄写入后再让调用方猜测状态。若业务允许保留前缀，可以改成只写入剩余空间并返回 io.ErrShortWrite，但处理请求体时通常直接拒绝更容易避免半截 JSON 或半个文件继续流转。

HTTP请求要在Body读取层再加一道限制

在 HTTP handler 中，建议把两道边界都保留。http.MaxBytesReader 专门限制传入的 Request.Body，官方文档说明它与 io.LimitReader 类似，但会在超过限制时返回 *http.MaxBytesError，并且实现了关闭底层 Reader 的责任。外层的 cappedBuffer 则保护这段业务缓冲区，避免未来有人把它复用到别的输入源时失去上限。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    const maxBody = int64(1  0 && r.ContentLength 

上例中 Content-Length 只是性能提示，不是安全边界：它可能未知，也可能与实际分块数据不一致。真正的边界来自读取器和 Writer 的运行时检查。若只想保护 HTTP 输入，可以保留 MaxBytesReader；若还要把缓冲区交给其他 io.Reader，则两层都值得保留。

复用Buffer时关注Reset、预分配和错误响应

Reset() 会清空未读数据但保留底层存储，适合请求之间复用对象；它不会把底层容量缩回上限，也不会替下一次写入建立新的限制。所以复用池中的结构体必须固定 limit，并在取出后确认没有把一个大容量 Buffer 带到不相干的请求。

我在这类代码里更愿意把“输入上限”和“业务缓冲上限”写成两个清晰的责任点：前者处理客户端发送过大的问题，后者保护内部接口被换成文件或消息流后的边界。两道检查让错误更早、更可读，也避免把内存分配失败当成正常业务分支。

常见问题

bytes.Buffer能不能直接设置最大容量？

不能。它公开了 Len、Cap 和 Grow，但没有最大容量字段；需要通过受限 Writer 或上游 Reader 限制输入。

只使用io.LimitReader够不够吗？

它能截断读取量，但业务还要判断是否真的读完以及是否超过阈值。HTTP 请求优先用 MaxBytesReader，通用流再配合受限 Writer。

为什么不直接捕获bytes.ErrTooLarge？

ErrTooLarge 对应的是无法分配时的 panic，不是可预期的请求错误。业务边界应在写入前检查，并返回可识别的错误类型。