c.Bind 无法处理大规模 JSON 数组，因其强制全量加载并要求目标为 struct；正确做法是用 json.NewDecoder 直接解析 c.Request().Body，配合 json.RawMessage 实现流式、低内存解码。
直接用 c.Bind 或 json.Unmarshal 处理大规模 JSON 数组请求，在 Echo 框架里必然 OOM 或 panic——它不支持流式，也不绕过标准库的全量加载逻辑。
为什么 c.Bind 不能处理大 JSON 数组
Echo 的 c.Bind 底层仍调用 json.Unmarshal，且要求目标变量是 struct 类型（不是 slice），所以传 []T 会报 binding element must be a struct；即使强行绕过，它也会把整个请求体读进内存再解析，对几百 MB 的 payload 来说等于主动申请 OOM。
- 错误现象：
binding element must be a struct或runtime: out of memory -
c.Bind设计用于表单、小结构体，不是为流式或大数组准备的 - 它内部调用
io.ReadAll(c.Request().Body)，和手动写io.ReadAll+json.Unmarshal内存行为完全一致
正确做法：用 json.NewDecoder 直接消费 c.Request().Body
别提前读整个 body，把 c.Request().Body 直接交给 json.NewDecoder，让解析器边读边解。这是唯一能压住内存在 KB 级的路径。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 如果请求体带 gzip，先套
gzip.NewReader(c.Request().Body) - 顶层是数组时，必须手动跳过
'['：调一次dec.Token()，确认返回json.Delim('[') - 用
for dec.More() { }循环，每次dec.Decode(&item)解一个元素，item可以是 struct、map[string]interface{}或json.RawMessage - 循环开头加
if !dec.More() { break }，防止多 decode 一次导致invalid character '}' after top-level value
字段动态或嵌套太深时，用 json.RawMessage 接住再按需解析
API 返回的 data 字段可能是对象、数组、字符串甚至 null，硬写 struct 会 panic；用 interface{} 则反射开销大、GC 压力高；json.RawMessage 是字节引用，零拷贝、零解析、可控粒度。
立即学习“go语言免费学习笔记（深入）”；
- 声明字段如：
Data json.RawMessage `json:"data"` - 后续只对真正需要的字段用
gjson.GetBytes(entry.Data, "user.id")提取，避免全量反序列化 - 注意：
map[string]json.RawMessage合法，但map[string]interface{}里放json.RawMessage会 panic - 别在循环里反复
json.Unmarshal同一块json.RawMessage——复用解码器实例更省
真正的难点不在“怎么写”，而在“怎么确保 body 不被多次读取”：一旦你调了 io.ReadAll 或 c.Bind，c.Request().Body 就已关闭或耗尽，后续 json.NewDecoder 会读到空。必须在 handler 开头就决定走哪条路——流式就全程流式，别混用。
