Golang实现复杂JSON字符串的流式解析与内存控制-Golang-PHP中文网

json.decoder比json.unmarshal更适合大json流，因其基于io.reader边读边解析，内存稳定在kb级；而unmarshal需一次性加载全部json到内存，易触发oom。

golang实现复杂json字符串的流式解析与内存控制

为什么 `json.Decoder` 比 `json.Unmarshal` 更适合大JSON流

因为 json.Unmarshal 必须把整个 JSON 字符串读进内存再解析，遇到几百MB的 JSON 文件或长连接中的持续 JSON 流，直接 OOM。而 json.Decoder 基于 io.Reader，边读边解析，内存只保留当前处理的 token 和结构体字段，峰值内存通常压在几 KB 到几十 KB。

常见错误是拿 bytes.NewReader([]byte{...}) 包一个超大字节数组传给 json.NewDecoder——这等于没省内存，只是换了个 API 调用方式。真正要配的是带缓冲的流式源头，比如 os.File、net.Conn 或带 bufio.Reader 的管道。

对文件：直接 os.Open("huge.json") → bufio.NewReader(f) → json.NewDecoder(bufReader)
对 HTTP 响应体：确保服务端返回的是 application/json 且未启用 gzip（或手动解压后再塞给 Decoder）
避免反复调用 decoder.Decode(&v) 解析单个顶层对象时传入指针为 nil 的变量，会 panic： panic: json: Unmarshal(nil *T)

如何安全解析嵌套深、字段多的 JSON 对象而不爆栈或卡死

深层嵌套（比如 500 层对象嵌套）会让默认的 json.Decoder 递归解析栈溢出；字段爆炸（如日志中带原始 HTML 片段或 base64 图片）会导致单次 Decode 卡住数秒甚至更久。解决方案不是调大栈，而是用 RawMessage + 按需解析。

例如，你只关心 data.items[].id 和 data.items[].status，其余字段体积大又无需结构化处理：

type Response struct {
    Data struct {
        Items []struct {
            ID     int           `json:"id"`
            Status string        `json:"status"`
            RawExt json.RawMessage `json:"ext"` // 不解析，留作字节切片
        } `json:"items"`
    } `json:"data"`
}

这样，每个 RawExt 只存引用（底层仍是原 JSON 字节的 subslice），不触发反序列化开销。后续若真需要解析某条 ext，再单独用 json.Unmarshal(item.RawExt, &extStruct)。

wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support

基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。

下载

注意 json.RawMessage 不能用于 map 的 value 类型（会 panic），只能用于 struct 字段或 slice 元素
如果字段名不固定（如动态 key），必须用 map[string]json.RawMessage，但要检查 key 是否合法，避免恶意构造的超长 key 耗尽内存
Decoder.DisallowUnknownFields() 在流式场景下慎用——它会在遇到未知字段时立即报错，而很多真实 API 返回字段是渐进式增加的

怎么控制每秒解析条数并防止 goroutine 泄漏

流式 JSON 常见于 Kafka 消息、WebSocket 推送或 SSE，如果上游发得快、下游处理慢，不加流控就会积压 goroutine，最终耗尽内存或 fd。关键不是“并发多少”，而是“一次 Decode 多少、间隔多久”。

推荐用带缓冲的 channel 控制消费节奏，配合 time.Tick 或令牌桶（简单起见用 time.Sleep）：

dec := json.NewDecoder(r)
for {
    var item MyItem
    if err := dec.Decode(&item); err == io.EOF {
        break
    } else if err != nil {
        log.Printf("decode error: %v", err)
        continue // 跳过坏数据，别 panic
    }
    select {
    case outChan

永远用 err == io.EOF 判断流结束，不要用 err != nil 统一处理——网络中断、编码错误、截断 JSON 都会返回其他 err，需区分对待
别在 for 循环里无条件启 goroutine 处理 item，除非你明确做了 worker pool 限流（比如用 semaphore.NewWeighted(10)）
如果 JSON 是数组格式（[{},{},{}]），标准 json.Decoder 默认只解第一个对象。需先读 [，再循环调用 Decode，直到遇到 ]；更稳妥的做法是用 jsoniter 或手动 tokenizer