gin.Context.BindJSON不能处理大数组，因其底层调用json.Unmarshal全量加载请求体，内存占用达文件大小2～3倍，且无法流式中断或复用body；应改用json.Decoder直接解析c.Request.Body，配合dec.More()和dec.Token()手动控制流式解码。
为什么 gin.Context.BindJSON 不能处理大数组
直接用 c.BindJSON(&slice) 解析 GB 级 JSON 数组必然 OOM。它底层调用 json.Unmarshal，必须先把整个请求体读进内存再解析——内存占用 ≈ 文件大小 × 2～3 倍。哪怕你只想要前 10 条，也会全量加载。
更隐蔽的问题是：Gin 的 BindJSON 会先调用 c.Request.Body.Read 把全部 body 读成 []byte，之后才交给 json.Unmarshal。这意味着你无法中途 abort、无法流式 discard、也无法复用 body（比如想 fallback 到其他格式解析）。
- 别写
c.BindJSON(&[]Item{})—— 这和json.Unmarshal行为一致，不是流式 - 别依赖
c.GetRawData()再传给json.Unmarshal—— 还是全量加载 - HTTP 请求体若带 gzip，
BindJSON会自动解压，但仍是全量解压后解析
如何用 json.Decoder 替代 BindJSON 实现真流式
核心是绕过 Gin 的绑定层，直接从 c.Request.Body 构造 json.Decoder，并手动推进 token 流。适用于 POST/PUT 请求体为纯 JSON 数组（如 [{"id":1},{"id":2}]）的场景。
- 先确认顶层是
'['：tok, _ := dec.Token()，再断言tok.(json.Delim) == '[' - 用
dec.More()控制循环边界，它内部自动识别逗号分隔和结尾']' - 每次循环内调
dec.Decode(&item)，item可以是 struct、map[string]interface{}或json.RawMessage - 如果请求体已 gzip 压缩，需包一层：
gzip.NewReader(c.Request.Body) - 记得在最后检查
err == io.EOF是否因意外截断导致，而非正常结束
结构体字段动态时用 json.RawMessage 避免 panic
当数组元素中某些字段类型不固定（比如 "metadata" 有时是 null、有时是 string、有时是 object），硬解到 struct 会导致 json: cannot unmarshal ... into Go struct field 错误。
立即学习“go语言免费学习笔记（深入）”；
正确做法是把这类字段声明为 json.RawMessage，跳过即时解析：
type LogEntry struct {
ID int `json:"id"`
Type string `json:"type"`
Metadata json.RawMessage `json:"metadata"`
}
- 后续按需解析：
json.Unmarshal(entry.Metadata, &target) - 避免因单个字段类型错位导致整条记录被丢弃
- 比
interface{}更轻量，不触发反射解析开销 - 注意：
json.RawMessage是[]byte别名，不可直接打印或比较，需先解码
逐条处理时如何控制内存与错误传播
流式解析不是“只要不 OOM 就万事大吉”。真实场景中常需写入数据库、发消息、校验逻辑，每一步都可能失败。必须把错误处理嵌入循环体内，且不能让单条失败中断整个流。
- 每次
dec.Decode(&item)后立即检查 err，err == io.EOF才是正常结束 - 遇到解析错误（如字段缺失、类型不符），可
log.Warn并continue，避免整批失败 - 若需原子性（如全部入库或全部回滚），流式本身不支持——得先缓存有限条目（如 100 条），再批量提交
- 别在循环里反复 new struct 实例；复用变量可减少 GC 压力（
var item Item放循环外） - 注意：
json.Decoder不会自动跳过空白，但默认兼容换行/缩进，无需预处理
真正难的不是写对第一行 json.NewDecoder，而是确保 dec.More() 和 dec.Decode() 的状态机不脱节——漏一次 More() 判断，或在 ] 后多 decode 一次，就会报 invalid character '}' after top-level value。这种错误不会在编译期暴露，只在数据边界上浮现。
