JSON解析内存暴涨是因为json.Unmarshal一次性加载完整JSON到内存；应改用json.Decoder流式解析，按需解码token或结构体，配合RawMessage延迟解析关键字段。
JSON 解析时内存暴涨，是因为 json.Unmarshal 一次性加载整个字节流
Go 标准库的 json.Unmarshal 要求输入是完整、合法的 JSON 文本（比如一个完整的对象或数组），它会把整个结构解码进内存。当处理 GB 级日志、流式 API 响应或嵌套很深的配置文件时，这直接导致 OOM 或 GC 压力飙升。
真正需要“增量解析”的场景，不是“分多次调用 json.Unmarshal”，而是跳过完整 AST 构建，边读边消费——核心工具是 json.Decoder，它包装 io.Reader，按需读取 token。
- 它不缓存整个输入，适合处理超长 JSON 数组（如
[{...},{...},{...}]） - 必须配合结构体字段标签（如
json:"name"）或手动 token 驱动，不能靠反射猜字段 - 遇到语法错误时，
Decode返回具体位置（如invalid character '}' looking for beginning of object key string），比Unmarshal更易定位
用 json.Decoder 流式解码 JSON 数组元素
这是最常见也最实用的增量解析模式：服务端返回一个大数组，客户端逐个处理每项，不保留历史。
关键点在于：不要把整个数组读进 []byte，而是让 Decoder 直接从 http.Response.Body 或文件 *os.File 读取；用循环反复调用 Decode，每次只解一个元素。
type User struct {
ID int `json:"id"`
Name string `json:"name"`
}
func processUsers(r io.Reader) error {
dec := json.NewDecoder(r)
// 先跳过 '['
if tok, err := dec.Token(); err != nil || tok != json.Delim('[') {
return fmt.Errorf("expected '[', got %v", tok)
}
for dec.More() {
var u User
if err := dec.Decode(&u); err != nil {
return err // 如遇 malformed item，可选择跳过或中断
}
process(u) // 自定义处理逻辑
}
return nil
}
-
dec.More()检查下一个 token 是否为,或]，避免手动判断边界 - 如果数组项结构不统一（比如混合
string和object），需先用dec.Token()判断类型，再分支解码 - 注意 HTTP Body 默认无缓冲，若网络延迟高，建议包一层
bufio.NewReader提升吞吐
手动 token 驱动解析：绕过结构体，直取关键字段
当只关心 JSON 中某几个字段（比如日志里的 "level" 和 "msg"），且结构极不规则时，用 Token() 手动遍历更轻量、更可控。
它返回 json.Token 接口值，可能是字符串、数字、Delim('[', '{') 或 nil，适合做条件提取或跳过大块无关数据。
func extractLevelAndMsg(r io.Reader) (string, string, error) {
dec := json.NewDecoder(r)
for {
t, err := dec.Token()
if err == io.EOF {
break
}
if err != nil {
return "", "", err
}
if s, ok := t.(string); ok && s == "level" {
if _, _ = dec.Token(); !ok { continue } // skip ':'
level, _ := dec.Token().(string)
return level, "", nil
}
// 同理处理 "msg"
}
return "", "", fmt.Errorf("not found")
}
- 每次
Token()只推进一个词法单元，不会自动跳过空白或换行，但也不强制要求格式化 - 无法直接获取嵌套路径（如
metadata.tags[0].name），需自己维护栈状态跟踪层级 - 性能比结构体解码高约 2–3 倍，但开发成本明显上升，仅在极端场景（如日志采集 agent）值得投入
别忽略 json.RawMessage：延迟解析 + 局部增量
有时 JSON 整体结构固定，但某个字段内容庞大或格式未定（如 "payload": {...}），这时用 json.RawMessage 把原始字节暂存，后续按需解析，既避免重复拷贝，又实现“局部增量”。
type Event struct {
ID int `json:"id"`
Type string `json:"type"`
Payload json.RawMessage `json:"payload"` // 不解码，只存 []byte 引用
}
func handleEvent(e Event) {
if e.Type == "user_created" {
var u User
json.Unmarshal(e.Payload, &u) // 仅此处触发解析
}
}
-
RawMessage是[]byte别名，解码时不做任何转换，零分配开销 - 注意：它保存的是源 JSON 的切片引用，若原始输入被复用（如重用
bytes.Buffer），需append([]byte{}, raw...)复制一份 - 和
Decoder组合使用时，可先用Decode得到顶层结构，再对RawMessage字段单独构造新Decoder进行子流解析
增量解析真正的难点不在 API 调用，而在状态管理：如何安全地恢复中断、如何处理不完整帧、怎么与上下文取消联动。标准库不提供这些，得靠你根据协议约定补全——比如在 TCP 流中，得先按长度头或分隔符切出单个 JSON 单元，再喂给 Decoder。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
