首页 > Golang > Go教程

Go JSON 解析怎样给单个字段设置大小上限

来源：17golang原创

时间：2026-10-21 23:22:19 436浏览收藏

可以，但要先分清两个问题：整个 JSON 请求能有多大，以及某个字段最多接受多少字节。Go 的 encoding/json 没有给单个字段单独挂载 Reader 的接口，比较稳妥的做法是：在入口限制请求体总量，在字段类型的 UnmarshalJSON 中拒绝超限值。

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

下面的示例把 content 限制为 64 KiB。这个限制是业务接受上限；它不能替代请求体限制，也不能宣称已经把解析器的内存分配变成硬隔离。

先分清两种大小上限

io.LimitReader 或 HTTP 层的 MaxBytesReader 只能限制输入总量，不能只对 JSON 中的一个字段生效。字段限制需要跟字段类型绑定，否则普通的 string 字段不会自动知道自己的业务上限。

HTTP 请求体、io.LimitReader、json.Decoder、LimitedString、字段字节数和业务结构体的两层边界关系说明图 — 图1：静态结构说明图，查看请求总量边界与字段接受边界的分工。

还要明确“长度”的单位。JSON 文本里的转义字符、引号和字段名属于原始 JSON 字节；解码后的 Go 字符串则应该按 UTF-8 字节数判断。若业务限制的是存储空间，通常检查解码后的 len(value) 更符合预期。

用自定义类型检查字段

把需要限制的字段从 string 换成一个小类型，并在 UnmarshalJSON 中先解码，再判断字符串的 UTF-8 字节数。超限时返回带字段名的错误，调用方就能把它和普通 JSON 语法错误区分开。

package main

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

const maxContentBytes = 64  maxContentBytes {
		return fmt.Errorf("content: %w: limit=%d bytes", ErrFieldTooLarge, maxContentBytes)
	}
	s.Value = value
	return nil
}

type Payload struct {
	Title   string        `json:"title"`
	Content LimitedString `json:"content"`
}

这种类型只约束明确使用它的字段；同一个结构体里的其他字符串仍按默认规则解析。需要限制多个字段时，可以为不同字段定义不同上限的类型，避免把一个隐含规则散落在业务层。

Decode 进入 Payload 和 LimitedString.UnmarshalJSON 后检查 JSON 原始字节、UTF-8 字节数并返回字段超限错误的结构说明图 — 图2：静态调用关系说明图，查看自定义字段类型的校验边界。

在 HTTP 入口限制整个请求体

字段类型的检查不能替代入口限流。服务接收 HTTP 请求时，先给 Body 设置总上限，再把受限 Reader 交给 json.Decoder。这样即使请求里没有 content 字段，也不会允许整个 JSON 无限增长。

func decodePayload(w http.ResponseWriter, r *http.Request) (Payload, error) {
	const maxBodyBytes = 1

如果不是 HTTP handler，也可以把输入包装成 io.LimitReader(reader, maxBodyBytes)。但要记住，LimitReader 到达上限时通常只表现为后续读取失败；对外接口最好把它转换成明确的“请求体过大”响应。

把错误边界说清楚

生产接口至少要区分四类情况：JSON 语法错误、字段类型错误、字段超限、整个请求体超限。它们的修复动作不同：前两类通常返回 400，字段超限可以返回带字段名的参数错误，整个请求体超限则应在 HTTP 层统一处理，避免把内部 Reader 错误直接暴露给客户端。

func classifyJSONError(err error) string {
	// 用 errors.Is 保留字段超限的业务语义，不依赖错误字符串匹配。
	if errors.Is(err, ErrFieldTooLarge) {
		return "field-too-large"
	}
	var syntaxErr *json.SyntaxError
	if errors.As(err, &syntaxErr) {
		return "invalid-json"
	}
	var typeErr *json.UnmarshalTypeError
	if errors.As(err, &typeErr) {
		return "wrong-field-type"
	}
	return "decode-failed"
}

最后的边界也很重要：自定义 UnmarshalJSON 适合做字段的业务接受规则，但如果面对不可信的大请求，真正的资源保护仍然应该前置到 HTTP Body、反向代理或协议设计层；极端场景还要考虑换成可逐项消费的流式格式。