Go json.Decoder.Token 怎么流式遍历超大数组

处理几百 MB 甚至更大的 JSON 数组时，真正容易出问题的不是语法，而是把整个数组一次性放进内存。更稳妥的方式是让 json.Decoder 从 io.Reader 读取：先用 Token() 确认数组边界，再用 More() 判断是否还有元素，用 Decode() 消费当前这一条。这样业务层只保留当前元素，不需要建立完整切片。

数组流式遍历的固定骨架是“读 [ → 循环 More() 并 Decode → 读 ]”。Token() 负责结构边界，Decode() 负责把单条记录落到具体类型。

先把超大数组拆成“边界”和“元素”

json.Unmarshal 适合已经在内存里的完整 JSON；它会把目标数组组织成完整切片。流式处理则把输入看成连续字节，解码器内部会自行缓冲，但调用者不必把所有记录收集起来。这里的关键不是把 JSON 变成“更小的 JSON”，而是每次只把一个元素交给业务代码。

读取数组时不要直接假定第一个 token 一定正确。先检查它是不是 json.Delim('[')，这样当接口误返回对象、错误文本或空内容时，可以在入口处给出明确错误。下面的结构体只表达文章场景，业务项目中可以替换成自己的字段。

用 More 加 Decode 按条处理记录

官方示例采用的组合很适合超大数组：读入开始分隔符后，在 dec.More() 为真时解码一个元素；循环结束，再读取关闭分隔符。处理函数应尽量在循环体内完成写入、校验或投递，不要把 Event 追加到一个无限增长的切片。

package main

import (
	"encoding/json"
	"fmt"
	"io"
	"log"
	"strings"
)

type Event struct {
	ID   string `json:"id"`
	Kind string `json:"kind"`
}

func main() {
	input := strings.NewReader(`[{"id":"a-1","kind":"login"},{"id":"a-2","kind":"logout"}]`)
	dec := json.NewDecoder(input)

	// 先确认输入确实从数组开始，避免把错误响应当成业务数据。
	tok, err := dec.Token()
	if err != nil {
		log.Fatal(err)
	}
	if delim, ok := tok.(json.Delim); !ok || delim != '[' {
		log.Fatalf("expected array start, got %v", tok)
	}

	count := 0
	for dec.More() {
		var event Event
		// 每轮只解码一条记录；处理完即可交给下游，不累积完整数组。
		if err := dec.Decode(&event); err != nil {
			log.Fatalf("decode item %d: %v", count, err)
		}
		fmt.Printf("%s %s\n", event.ID, event.Kind)
		count++
	}

	// More 返回 false 只代表当前数组没有更多元素，仍要消费结束分隔符。
	tok, err = dec.Token()
	if err != nil && err != io.EOF {
		log.Fatal(err)
	}
	if tok != json.Delim(']') {
		log.Fatalf("expected array end, got %v", tok)
	}
	fmt.Println("processed:", count)
}

这里的内存优势来自“不保存全量结果”，不是来自 Token() 会自动限制单条元素大小。如果数组中的某一项本身就是一个巨大的嵌套对象，Decode 到结构体时仍要为这一个对象分配空间；需要进一步控制时，要把字段拆开处理或重新设计输入格式。

需要动态结构时再逐个读取 Token

数组元素结构不稳定、只想筛选某个键，或者需要记录解析偏移时，可以直接读取 token。Token() 会返回 json.Delim、字符串、布尔值、null，以及默认的 float64 数字；逗号和冒号不会单独返回。嵌套对象不能只看一层 token，要用深度计数或把完整元素交给 Decode。

// scanNumbers 展示动态数组中保留数字文本的做法。
func scanNumbers(r io.Reader) error {
	dec := json.NewDecoder(r)
	// UseNumber 避免默认 float64 造成大整数精度损失。
	dec.UseNumber()

	start, err := dec.Token()
	if err != nil {
		return err
	}
	if start != json.Delim('[') {
		return fmt.Errorf("not an array: %v", start)
	}
	for dec.More() {
		tok, err := dec.Token()
		if err != nil {
			return err
		}
		// json.Number 保留输入形式，业务层再决定 Int64 或 Decimal 解析策略。
		if number, ok := tok.(json.Number); ok {
			fmt.Println("number:", number.String())
		}
	}
	_, err = dec.Token()
	return err
}

如果元素是对象，直接连续读取 token 会同时遇到字段名、值和嵌套分隔符，代码很快会变成手写解析器。可维护的取舍通常是：外层用 Token 控制数组，元素内部仍用 Decode；只有确实需要动态字段或原始数字文本时，才下沉到 token 级别。

结束分隔符、错误和输入边界怎么处理

Token() 对不匹配的数组、对象分隔符会返回错误，因此不要为了“继续处理后面的数据”而无条件忽略 error。另一个容易忽略的边界是 NewDecoder 可能提前从底层 Reader 读取更多字节；如果同一个 Reader 后面还有别的协议内容，只有在明确理解 Buffered() 语义后再拼接剩余数据。

相关问题

Token 和 Decode 能在同一个 Decoder 中交替使用吗

可以。外层用 Token 读取数组边界，数组元素用 Decode 读取完整值，是官方流式数组示例采用的方式。关键是保持当前 JSON 层级，不要跳过未消费的结束分隔符。

为什么遍历大数组后内存仍然上涨

常见原因是业务代码仍在保存所有元素，或者单条元素本身很大。先检查是否不断 append，再看下游缓存、批量提交和日志是否有无界队列。

什么时候应该不用 Token

如果输入体量可控、结构固定且需要完整随机访问，直接 Decode 到结构体或切片更简单。Token 适合流式边界、动态结构和增量处理，不是所有 JSON 都要手动拆成 token。