首页 > Golang > Go教程

Go encoding/json Decoder 如何拒绝尾随数据：单个 JSON 文档的结束判定

来源：17golang原创

时间：2026-08-27 01:41:15 494浏览收藏

接口把请求体交给 json.Decoder 后，第一次 Decode 返回 nil，只能说明“读到了一个合法 JSON 值”，不能证明后面没有第二段 JSON 或多余字节。需要把单文档接口和 JSON 流区分开：单文档场景在第一次成功后再调用一次 Decode，只有得到 io.EOF 才能确认输入已经结束。

要点速览

一次 Decode 成功不等于整个请求体校验完成。
单个 JSON 文档应在首个值后再次调用 Decode，并要求错误是 io.EOF。
第二次仍读到合法值，或返回非 EOF 错误，都应拒绝请求。
如果业务本来就是 JSONL 或多文档流，就不要套用单文档规则。

先看一个“明明能解析却不该放行”的请求

下面的输入包含两个 JSON 值，中间只有空白。对一个只接受用户资料的接口来说，第二个对象不是“忽略掉的尾巴”，而是请求格式不符合约定：

{"name":"Lin"} {"role":"admin"}

很多 handler 只写到第一次 Decode(&payload) 就返回 200，于是第一个对象被使用，第二个对象悄悄留在请求体中。这个判断漏洞不需要复杂攻击技巧，客户端多发一段内容就能复现。

Go encoding/json Decoder 第一次 Decode 成功后仍有第二个 JSON 值留在请求体尾部的校验现场

单文档接口的最小校验流程

把读取过程拆成两个门禁即可。第一步解析业务对象；第二步继续读一次，只接受 io.EOF：

func decodeOne(r io.Reader, dst any) error {
    dec := json.NewDecoder(r)

    if err := dec.Decode(dst); err != nil {
        return fmt.Errorf("decode body: %w", err)
    }

    var extra any
    if err := dec.Decode(&extra); err != io.EOF {
        if err == nil {
            return errors.New("request body contains more than one JSON value")
        }
        return fmt.Errorf("trailing data: %w", err)
    }
    return nil
}

这里的 err != io.EOF 是关键。第二次返回 nil 表示又读到了一个完整 JSON 值；返回其他错误表示尾部还有不完整或非法内容；这两类都不是单文档请求的结束状态。

Go Decoder 第二次 Decode 读取请求尾部并得到 io.EOF，单个 JSON 文档通过结束判定

把它接到 HTTP handler 时，响应边界要保持稳定

在 HTTP 服务里，解析错误和尾随数据都应该转换成固定的 400 响应，不要把底层错误全文直接返回给客户端。一个紧凑的 handler 可以这样写：

type profileInput struct {
    Name string `json:"name"`
}

func profile(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close()

    var input profileInput
    if err := decodeOne(r.Body, &input); err != nil {
        http.Error(w, "invalid JSON body", http.StatusBadRequest)
        return
    }
    if input.Name == "" {
        http.Error(w, "name is required", http.StatusBadRequest)
        return
    }
    w.WriteHeader(http.StatusNoContent)
}

这条流水线的验收点也很明确：合法单对象返回 204；两个连续对象返回 400；只有空白尾部的对象仍返回 204；首个值不完整或类型错误同样返回 400。