Go json.Decoder 怎样限制单次读取大小

Go 的 json.Decoder 没有“每次 Decode 最多读取多少字节”的设置。需要限制输入时，应在 Reader 外层设置字节预算；如果接口只允许一个 JSON 文档，还要处理文档后面的内容。这里的限制对象是一次完整输入，不是底层每次 Read 的缓冲区长度。

如果我要为一个小型 JSON 接口选择方案，我会先把完整输入限制在明确的字节数内，再解析它。这个选择会多保留一份输入字节，但大小判断更直接；它不是大型文件流式导入方案，也不是进程内存的精确配额。

Go 官方文档：https://pkg.go.dev/encoding/json

一次 Decode 并不等于一个固定读取窗口

Decoder 自带缓冲，可能从底层 Reader 读取超出当前 JSON 值的数据。因此，缩小传给 Read 的切片或观察 InputOffset，都不能代替完整输入限制。这里要保护的是接口接收和解析输入的资源预算：正文过大、一个有效对象后附带其他内容，都应该在业务操作之前被处理。

本文将策略定为：完整输入上限 1 MiB，包含 JSON 空白；只接受一个可解码为 Payload 的值。1 MiB 只是示例配置，不是标准推荐值。null 的接受与否属于业务语义，本例沿用 encoding/json 的行为，不额外判定。

LimitReader 多留一个字节，才能明确判断超限

io.LimitReader 达到指定字节数后返回 EOF。只限制到 N，无法仅凭 EOF 知道源输入是否还有内容。下面最多读取 N+1 字节：如果长度大于 N，就返回 ErrTooLarge；否则再处理读取错误和 JSON 解析。读取上限是字节，不是汉字个数。

package boundedjson

import (
    "bytes"
    "encoding/json"
    "errors"
    "fmt"
    "io"
)

const maxInput int64 = 1  maxInput {
        return out, ErrTooLarge
    }
    if err != nil {
        return out, fmt.Errorf("read input: %w", err)
    }
    dec := json.NewDecoder(bytes.NewReader(data))
    if err := dec.Decode(&out); err != nil {
        return Payload{}, fmt.Errorf("decode input: %w", err)
    }
    // 同一个Decoder检查尾部，避免遗漏其内部预读缓冲。
    var extra any
    if err := dec.Decode(&extra); err != io.EOF {
        if err == nil {
            return Payload{}, errors.New("multiple JSON values")
        }
        return Payload{}, fmt.Errorf("trailing input: %w", err)
    }
    return out, nil
}

这段原创示例没有在本机执行。调用者负责关闭传入的文件或请求体；函数只接收 io.Reader，不擅自关闭资源。限额是固定常量，避免把不受信任的参数直接加一导致溢出。ReadAll 的切片容量、Decoder 缓冲和解码对象还会消耗额外内存，不能把 N+1 当成全部内存占用。

尾部检查必须继续使用同一个 Decoder

首次 Decode 成功后，再用同一个 Decoder 读取第二个值，并要求得到 io.EOF。第二个值解码成功时拒绝多值输入；其他错误表示尾部不可接受。不要直接改读原始 Reader，因为已经预读的字节可能仍在 Decoder 内部。

我更看重这个实现的错误边界是否容易解释：超限优先于解析，接着才是首值错误和尾部错误。对于小型管理接口，这个可解释性通常比省掉有界字节切片更重要。需要连续读取多个 JSON 值的协议则不应套用“第二次必须 EOF”的规则，而应先设计消息分帧和每条消息预算。

HTTP 请求体再用 MaxBytesReader 表达超限

net/http 提供 MaxBytesReader，在越过上限的读取中返回 *http.MaxBytesError，并保留 Close 语义。可以把它和前面的函数组合；ReadPayload 会通过包装错误保留读取错误链。以下为处理器片段，不是可单独编译的完整服务：

// 以下片段放在HTTP处理器内；导入errors、io、net/http及boundedjson包。
r.Body = http.MaxBytesReader(w, r.Body, 1

上面的 io 导入并非片段必需，可省略；实际应用按所在文件使用的符号整理导入。错误分类使用 errors.As 和 errors.Is，不匹配英文错误文本。仅做一次 Decode 就返回成功，可能根本没有触及后面的超量内容；示例通过有界读取完整输入避免这一点。Content-Length 只能作为提前拒绝的辅助条件，不能取代实际读取限制。

把边界样例和错误类别写清楚

可记录请求标识、配置限额、错误类别和响应码，不记录完整请求正文。以下是供读者自行测试的预期行为，不是实测记录：

能限制每个 Read 最多读取几字节吗？

自定义 Reader 可以缩小每次读取窗口，但累计输入仍可能无限增长。这与本文限制整个输入的目标不同。

限制字节数后还需要超时吗？

需要另行考虑读取时间。字节上限不保证源 Reader 在限定时间内返回；生产接口应由所属服务器和连接策略管理读取时限，本例不展开配置。

能对压缩内容直接沿用这个上限吗？

先明确限额针对哪一层。若 Reader 已经是解压后的数据，本文预算约束的是解压后输入；不能自动代表网络上传输的压缩体大小。

我的选择是把“输入有界、只有一个值、错误可分类”作为小型 JSON 接口的三个独立要求。不要试图用一次 Decode 或一个看似很小的缓冲区同时满足它们。

相关官方文档：https://pkg.go.dev/io#LimitReader；https://pkg.go.dev/net/http#MaxBytesReader；https://pkg.go.dev/encoding/json#Decoder。