shouldbindjson会将整个请求体读入内存导致oom，正确做法是绕过框架绑定，用json.newdecoder直接流式解析body，并处理gzip、手动跳过数组边界、配合dec.more()循环解码单个元素。
ShouldBindJSON 会把整个请求体读进内存，大 JSON 直接 OOM
只要请求体超过几 MB，ShouldBindJSON 就大概率触发 panic: runtime: out of memory。它底层调用 json.Unmarshal，必须先把 c.Request.Body 全部读成 []byte，再反射解析——内存占用通常是原始数据的 2～3 倍。
常见错误现象包括：服务偶尔卡死、GC 频繁暂停、CPU 占用突增但无明显日志、K8s Pod 被 OOMKilled。
- 别在 handler 里写
c.ShouldBindJSON(&v)处理日志包、原始埋点、设备快照这类体积不可控的 payload - 即使只取前 3 个字段，
ShouldBindJSON仍会加载全部内容 - 框架中间件（如
gin.Recovery()）无法拦截这种 OOM，崩溃发生在绑定阶段之前
绕过 ShouldBindJSON，用 json.NewDecoder 直接读 Body
核心是把 c.Request.Body 当作流处理，而不是字符串或字节切片。关键点在于：不调 io.ReadAll，不碰 c.Request.Body 两次（Body 只能读一次），且要处理 gzip。
- 先检查
c.GetHeader("Content-Encoding") == "gzip"，如果是，用gzip.NewReader(c.Request.Body)包一层再传给json.NewDecoder - 直接传
c.Request.Body给json.NewDecoder，不要先io.Copy(ioutil.Discard, c.Request.Body)或其他消耗操作 - 如果后续还要复用 Body（比如记录原始 payload），得用
io.TeeReader或提前httputil.DumpRequest保存副本
顶层是数组时，必须手动跳过 '[' 并用 dec.More()
遇到形如 [{"id":1},{"id":2},...] 的批量数据，decoder.Decode(&[]T{}) 仍是全量加载——这不是流式，是假流式。
正确做法是三步推进：
- 调
dec.Token()检查并跳过第一个json.Delim('{')或json.Delim('[') - 用
for dec.More() { ... }循环，dec.More()内部自动识别逗号分隔和结尾]或} - 每次循环内调
dec.Decode(&item)，item类型可以是struct、map[string]interface{}或json.RawMessage - 漏掉
dec.More()判断，或写成for { if err == io.EOF { break } }，会在末尾多 decode 一次，报错invalid character '}' after top-level value
字段动态或嵌套深时，用 json.RawMessage 而不是 interface{}
interface{} 看似灵活，但对超大嵌套对象（比如带 50 层嵌套的 metadata）会引发深度递归解析、栈溢出或 panic；而 json.RawMessage 只存原始字节片段，零拷贝、零解析开销。
- 声明字段为
Metadata json.RawMessage `json:"metadata"`，后续按需json.Unmarshal(entry.Metadata, &target) - 避免在循环里反复调
jsonvalue.Get().GetString()—— 每次都从头遍历路径，应一次Get()后缓存返回的*jsonvalue.Value - 如果只是过滤（如含关键词
"error"），直接用bytes.Contains(entry.Metadata, []byte("error"))，比任何 JSON 解析都快
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
