Go encoding/json/v2 怎样选择严格重复键处理策略在批处理代码中减少额外分配

批处理 JSON 时，重复键不能只当成“最后一个值覆盖前一个值”的小细节：鉴权服务和业务服务如果采用不同解释，得到的用户或权限可能不一致。Go 1.27 的 encoding/json/v2 默认拒绝对象中的重复名称，适合外部请求和不可信文件；只有明确接收旧格式时，才在一个很窄的兼容入口启用 jsontext.AllowDuplicateNames(true)。

先把重复键策略放在输入边界

v2 默认拒绝同一个 JSON 对象里的重复名称，和 v1 允许重复名称的行为不同。严格模式的价值不只是报错，而是让所有下游看到同一个确定语义；这也是批处理入口最省事的方案：一次解码同时完成语法检查、重复名称检查和结构体填充，没有额外的预扫描容器。

真正需要兼容的情况通常来自历史导出文件或已经约定俗成的内部格式。此时不要把宽松选项散落到每个调用点，而应由入口参数表达来源，后面的业务函数只接收已经决定好的结构体。

用一次解码完成严格检查和结构体填充

下面的函数把兼容开关收在一个位置。严格路径没有 map[string]json.RawMessage、jsontext.Value 等中间对象，批量处理时更容易控制分配；错误也保留了当前记录的边界，调用方可以选择跳过坏记录或终止整个批次。

package batchjson

import (
    "fmt"

    "encoding/json/jsontext"
    "encoding/json/v2"
)

type BatchRecord struct {
    ID    string `json:"id"`
    State string `json:"state"`
}

func decodeRecord(data []byte, allowLegacyDuplicate bool) (BatchRecord, error) {
    // 每次返回独立的值，避免调用方把错误记录继续交给业务层。
    var record BatchRecord
    if allowLegacyDuplicate {
        // 只对已知遗留来源放宽；重复名称按输入顺序处理。
        if err := json.Unmarshal(data, &record, jsontext.AllowDuplicateNames(true)); err != nil {
            return BatchRecord{}, fmt.Errorf("decode legacy record: %w", err)
        }
        return record, nil
    }
    // 默认路径同时执行语法、重复名称和目标字段的解码。
    if err := json.Unmarshal(data, &record); err != nil {
        return BatchRecord{}, fmt.Errorf("decode strict record: %w", err)
    }
    return record, nil
}

这里的“减少额外分配”不是承诺固定的分配次数，而是避免为了重复键再走一遍 JSON。是否值得进一步优化，应以 go test -bench 和 -benchmem 的结果为准；如果每条记录很小，日志格式化或上游切片复制反而可能更显著。

批处理复用值时先清零，再决定错误去向

如果为了减少对象创建而复用一个结构体，下一条 JSON 缺少某个字段时，旧值可能继续存在。进入循环前把目标值恢复为零值，是性能和正确性之间成本很低的护栏。

func processBatch(payloads [][]byte, allowLegacyDuplicate bool) error {
    var record BatchRecord
    for index, payload := range payloads {
        // 复用结构体前清零，防止缺失字段继承上一条记录。
        record = BatchRecord{}

        var err error
        if allowLegacyDuplicate {
            // 兼容开关仍由批次来源控制，不对单条数据临时放宽。
            err = json.Unmarshal(payload, &record, jsontext.AllowDuplicateNames(true))
        } else {
            // 外部或不可信输入保持严格重复键策略。
            err = json.Unmarshal(payload, &record)
        }
        if err != nil {
            // 这里选择跳过坏记录；资金、权限等批次应改为直接返回错误。
            fmt.Printf("skip record %d: %v\n", index, err)
            continue
        }
        handle(record)
    }
    return nil
}

生产代码里可以把 fmt.Printf 换成带批次 ID 的结构化日志。不要仅因为想省一次分配，就复用一个已经被下游异步保存的指针；如果记录会跨出当前循环，应该复制到明确拥有生命周期的对象。

用基准测试验证分配，而不是凭感觉改策略

把严格解码、遗留兼容解码和“先转中间结构再解码”分别放入基准测试。测试数据应包含正常记录、重复键记录和缺失字段记录，并分别观察吞吐、allocs/op 与错误比例。严格模式失败是预期行为，不能为了让基准全绿而吞掉错误。

结论可以按这条规则落地：不可信输入坚持默认严格；旧数据兼容只在适配器开关；只有测得中间预扫描确实解决了额外需求，才保留它。这样既避免重复键带来的语义歧义，也不会为了安全检查在每条记录前再制造一套对象。

相关问题

允许重复键后哪个值会生效？

成员按出现顺序处理，后续值会替换或合并到先前值，具体取决于目标 Go 类型。因此宽松模式必须绑定明确的遗留输入。

严格模式需要先用 map 查重吗？

不需要。encoding/json/v2 默认已经拒绝重复名称，直接解码到目标类型即可。

复用结构体一定比每条新建更快吗？

不一定。复用会引入清零和生命周期约束，应结合 -benchmem 测量；异步持有记录时，安全的所有权比少一次分配更重要。