Go JSON v2 怎样拒绝重复对象键

Go JSON v2 处理重复对象键时，默认就是拒绝：同一个 JSON 对象里第二次出现相同名称，会让 json.Unmarshal 返回错误，而不会静默采用最后一个值。接口接收外部 JSON 时，保留这个默认值通常更稳；只有在明确兼容历史数据时，才考虑放宽。

Go JSON v2 默认为什么会拒绝重复键

旧的 encoding/json 允许重复名称，解码到结构体或 map 时容易形成“最后一次覆盖”之类的隐含约定。JSON 标准没有规定重复名称的统一解释，不同实现可能得出不同结果。v2 选择拒绝，目的是让输入在跨语言传递时更可预测。

最小处理函数只需要检查返回错误：

package main

import (
    "fmt"

    "encoding/json/v2"
)

type Request struct {
    User string `json:"user"`
}

func main() {
    // 两个 user 使用同一对象名称，v2 默认会拒绝整个输入。
    input := []byte(`{"user":"alice","user":"bob"}`)
    var req Request
    if err := json.Unmarshal(input, &req); err != nil {
        // 不把后一个值当成可信结果，直接交给上层处理。
        fmt.Println("invalid JSON object:", err)
        return
    }
    fmt.Println(req.User)
}

这里的“重复”针对同一个对象内的名称。嵌套对象各自拥有独立的名称空间；真正要防的是同一层对象的输入含义被覆盖或合并。也不要把这个错误和 JSON 语法错误混为一谈：文本可以语法正确，却因为重复名称而无法按 v2 语义解码。

用 SemanticError 把错误边界交给调用方

接口层不必把完整内部错误原样暴露给客户端，但可以先用 errors.As 取出 json.SemanticError，记录偏移和 JSON Pointer，再返回稳定的错误码。这个错误类型还包含底层 Err，适合日志关联。

package main

import (
    "errors"
    "fmt"
    "net/http"

    "encoding/json/v2"
)

type Request struct {
    User string `json:"user"`
}

func decodeRequest(w http.ResponseWriter, body []byte) {
    // 目标是拒绝歧义输入，而不是猜测哪个 user 更可信。
    var req Request
    if err := json.Unmarshal(body, &req); err != nil {
        var semErr *json.SemanticError
        if errors.As(err, &semErr) {
            // 偏移和路径用于服务端日志，客户端只拿稳定提示。
            fmt.Printf("json semantic error: offset=%d pointer=%s cause=%v\n",
                semErr.ByteOffset, semErr.JSONPointer, semErr.Err)
        }
        http.Error(w, "request JSON contains an invalid object", http.StatusBadRequest)
        return
    }
    _ = req
}

ByteOffset 适合定位原始字节，JSONPointer 适合关联对象路径；两者都应视作诊断信息，而不是客户端协议的永久字段。若输入在网关已经被截断，偏移仍只能说明解码器看到的内容，不能替代请求体完整性检查。

什么时候才使用 AllowDuplicateNames

默认拒绝已经足够表达严格策略，也可以在公共解码函数里显式写出来，让决策不依赖读者记忆：

import "encoding/json/jsontext"

// 显式保留 v2 的严格重复名称策略。
err := json.Unmarshal(input, &req, jsontext.AllowDuplicateNames(false))

如果确实要读取旧系统生成的重复键数据，才传入 jsontext.AllowDuplicateNames(true)。这不是“只忽略错误”：成员会按输入顺序处理，后面的值可能替换或合并之前的值，而且不同目标类型的结果不同。放宽后应把数据转换到内部唯一键结构，再进入业务逻辑，避免重复语义继续向下游传播。

另外，foo 与 Foo 是否算同一字段，还受到字段名称匹配策略影响。不要在开启大小写不敏感匹配后，又假设所有输入实现都按严格区分大小写；跨语言协议最好统一字段名并保持默认严格匹配。

上线前的重复键处理清单

常见问题

重复键会自动保留最后一个值吗？

在 JSON v2 默认策略下不会进入成功解码结果，而是返回错误。只有显式允许重复名称时，才会按出现顺序处理，不能把“最后一个值”当成通用保证。

只设置 RejectUnknownMembers 能拒绝重复键吗？

不能。RejectUnknownMembers 解决未知字段，重复名称由 jsontext.AllowDuplicateNames 控制；两者是独立的输入策略。

参考：https://pkg.go.dev/encoding/json/v2；https://go.dev/doc/jsonv2-migration。如果业务没有兼容旧数据的明确需求，保留 v2 默认拒绝，再把 SemanticError 转成清晰的接口错误，通常是最小且可维护的方案。