Go json.Valid 怎样快速判断输入是不是完整 JSON

处理接口请求、消息队列或配置文件时，我通常先问一个很窄的问题：这段字节是不是一份完整的 JSON？如果只需要回答“是”或“否”，Go 标准库的 json.Valid 就够了。它检查的是 JSON 语法，不会把数据解析成结构体，也不会替你判断业务字段。

最实用的顺序是：先用 json.Valid(data) 拦住截断、缺括号和多余顶层内容；返回 true 后，再按需要调用 json.Unmarshal 做类型解析，最后执行必填字段、范围和业务状态校验。

先用 json.Valid 判断一份完整 JSON

json.Valid 的签名是 func Valid(data []byte) bool。它接收字节切片，返回这段数据是否构成一份合法的 JSON 编码。对象、数组、字符串、数字、true、false 和 null 都可能是合法的顶层值，不要把“合法 JSON”误解成“必须是对象”。

下面的例子把三类输入放在一起：完整对象应该通过，缺少结尾花括号的内容应该失败，而两个顶层对象拼接在一起也不再是一份 JSON 文档。

package main

import (
	"encoding/json"
	"fmt"
)

func main() {
	samples := map[string][]byte{
		"完整对象":   []byte(`{"name":"go","enabled":true}`),
		"截断对象":   []byte(`{"name":"go"`),
		"两个顶层值": []byte(`{"id":1}{"id":2}`),
	}

	for name, data := range samples {
		// Valid 只做 JSON 语法判断，结果适合用作入口分支。
		fmt.Printf("%s: %t\n", name, json.Valid(data))
	}
}

这段程序的关键不是输出格式，而是判断对象边界：json.Valid 只在整段字节能够被 JSON 语法完整消费时返回 true。它不会返回错误位置；如果调用方需要把错误类型、字段或偏移量告诉用户，就要进入下一层解析。

空输入、空白和多余内容要分开看

JSON 允许在值的外侧出现空白，所以前后带空格、换行或制表符的单个值仍然可能合法。例如 {"ok":true} 可以通过判断。相反，空切片和只包含空白的切片没有 JSON 值，应该返回 false。

func isCompleteJSON(data []byte) bool {
	// 空输入和纯空白没有顶层 JSON 值，直接交给 Valid 统一判断即可。
	return json.Valid(data)
}

func main() {
	tests := [][]byte{
		{},
		[]byte(" \n\t"),
		[]byte(" \n{\"ok\":true}\t"),
		[]byte("null"),
	}

	for _, data := range tests {
		// 输出块只展示调用结果，不把日志当作代码注释。
		fmt.Println(isCompleteJSON(data))
	}
}

另一个容易忽略的边界是“多余非空白字符”。例如 true false 不是一个包含两个元素的 JSON 数组，而是两个顶层值拼接；如果业务协议本来就是连续 JSON 流，应使用 json.Decoder 逐个读取，而不是把整个流交给 json.Valid。

json.Valid 只做语法校验，不做字段校验

这一步是最重要的职责边界。json.Valid 能发现引号、括号、逗号等 JSON 语法问题，但它不知道你的结构体是否缺少 name，也不知道 count 是否应该是整数，更不会识别状态值是否允许。

因此，下面两层检查应该分开写：第一层快速挡住格式损坏，第二层把合法 JSON 映射为 Go 类型并处理解析错误。

type Request struct {
	Name  string `json:"name"`
	Count int    `json:"count"`
}

func decodeRequest(data []byte) (Request, error) {
	var request Request

	// 先区分语法错误，避免把截断请求误报成字段问题。
	if !json.Valid(data) {
		return Request{}, fmt.Errorf("请求体不是完整 JSON")
	}
	// Unmarshal 再负责类型转换和目标结构的解析错误。
	if err := json.Unmarshal(data, &request); err != nil {
		return Request{}, fmt.Errorf("解析请求体失败: %w", err)
	}
	// 必填字段和取值范围属于业务规则，不由 json.Valid 决定。
	if request.Name == "" {
		return Request{}, fmt.Errorf("name 不能为空")
	}
	return request, nil
}

例如 {"count":"很多"} 在 JSON 语法上是合法的，但把它解码到 int 字段时会出现类型错误；而 {"count":1} 可能顺利解码，却仍然缺少业务要求的 name。这三种状态不能用一个布尔值混为一谈。

按数据来源选择 Valid、Unmarshal 还是 Decoder

可以把三个入口理解成不同层次的工具，而不是互相替代：

如果数据已经在内存里、只是想做一次语法预检，调用 json.Valid 最直接。如果下一步必然要得到结构体，也可以直接 json.Unmarshal，因为它本身会同时进行语法解析和类型解码。对于大文件或连续输入，不要为了调用 Valid 先把全部内容读进内存，应该围绕 Decoder 设计读取边界。

func validateBody(data []byte) error {
	// 该函数只负责格式层，业务层可以在调用方继续检查字段。
	if !json.Valid(data) {
		return fmt.Errorf("body 不是完整 JSON")
	}
	return nil
}

把入口顺序固定成三层

在实际接口里，我会把判断顺序固定为“语法、类型、业务”。这样日志和返回信息更容易解释，也不会在字段校验函数里重复处理括号缺失的问题。

1. 语法层：对已经读入内存的原始字节调用 json.Valid，识别空输入、截断 JSON 和多余顶层值。
2. 类型层：用 json.Unmarshal 或 json.Decoder.Decode 映射到 Go 类型，处理数字、字符串和目标类型不匹配。
3. 业务层：检查必填字段、范围、状态转换和权限条件，并返回面向调用方的业务错误。

如果只需要一个布尔值，直接返回 json.Valid(data)；如果要告诉调用方“第几行、第几个字段出错”，不要继续扩展 Valid 的职责，应该保留后续解析错误或使用更适合流式输入的 Decoder。

常见问题

json.Valid 能判断 JSON 是否符合结构体字段要求吗？

不能。它只判断 JSON 语法，字段是否存在、类型是否正确和取值是否满足业务规则，需要 Unmarshal、Decoder 以及单独的业务校验。

为什么两个看起来都合法的对象拼接后返回 false？

因为 json.Valid 判断的是一整段数据是否构成一个 JSON 编码。两个顶层对象应改成数组，或使用 Decoder 按连续值读取。

空字符串和 JSON 字符串空值是一回事吗？

不是。空字节没有 JSON 值；"" 则是合法的 JSON 字符串。是否允许空字符串，还要由业务字段规则决定。

总结

json.Valid 最适合做轻量、明确的语法层判断：它告诉你一段字节是否是完整 JSON，但不负责类型解析和业务验收。内存中的单个值可以继续交给 Unmarshal，连续输入则应使用 Decoder。把这三层职责分开，接口排障时就能准确区分“格式坏了”“类型不匹配”和“业务不允许”。