应使用json.Decoder配合Token()和More()手动解析JSON数组，避免json.Unmarshal或Decode(&[]T)全量加载导致OOM；核心是跳过'['、循环Decode单个元素，内存稳定在KB级。
直接用 json.Unmarshal 或 decoder.Decode(&[]T) 读超大规模 JSON 文件，99% 的概率触发 runtime: out of memory。唯一可靠路径是放弃“整块加载”，改用 json.Decoder 配合手动 token 控制，把内存压在几百 KB 级别。
为什么 decoder.Decode(&[]T) 依然 OOM
它看似流式，实则仍需一次性分配底层数组并填满全部元素——文件含 100 万条记录，Go 就会 malloc 100 万个 struct 实例，外加 slice 扩容的冗余空间。哪怕你只取前 10 条，整个数组结构也得建完。
-
decoder.Decode(&[]T)和json.Unmarshal在内存行为上本质相同，只是读取来源不同 - 错误现象：
fatal error: runtime: out of memory或 GC 频繁卡顿，pprof显示runtime.mallocgc占比超高 - 真正流式 ≠ 自动分片，而是你得自己控制“何时读、读多少、读到哪停”
正确解析顶层为 JSON 数组的三步法
核心是绕过自动容器解析，用 Token() 进入上下文，再靠 dec.More() 控制循环边界。适用于 [{...},{...},...] 格式。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 第一步：调一次
dec.Token()，确认返回值是json.Delim('[')；如果不是，说明开头有 BOM、空格或换行，需预处理 - 第二步：进入
for dec.More() { ... }循环；dec.More()内部会识别逗号分隔和结尾]，无需手动跳, - 第三步：每次循环内调
dec.Decode(&item)；item可为map[string]interface{}、自定义 struct 或json.RawMessage - 关键兜底：循环体开头加
if !dec.More() { break }，避免dec.Decode()在]后多读一次，引发invalid character '}' after top-level value
字段动态或结构混杂时怎么保活
日志、ETL 数据常含不同 "type" 字段的对象，硬写 struct 容易 panic。此时不应妥协成 map[string]interface{}（它会强制解析所有键值，生成大量小对象），而应精准控制解析粒度。
立即学习“go语言免费学习笔记（深入）”；
- 把不确定字段声明为
json.RawMessage，例如Metadata json.RawMessage `json:"metadata"` - 只对真正需要的字段做结构体绑定，其余字段延迟到业务逻辑中按需
json.Unmarshal - 若需快速过滤（如只取
"type": "event"），先用json.RawMessage拿到整块字节，再用gjson.GetBytes提取type字段，避免全量反序列化 - 切忌在循环里反复
make([]byte, len(raw))—— 改用sync.Pool复用缓冲区，或直接append([]byte(nil), raw...)显式拷贝
别踩这些隐形坑
很多问题不是代码写错，而是底层行为被忽略：Decoder 不会自动 rewind，os.File 的 offset 是全局的，json.RawMessage 持有的是原始字节切片引用，复用 struct 实例时字段不会自动清零。
- 用
os.Open后别再调file.Seek(0, 0)重试——除非你明确知道 offset 已偏移；多数 OOM 场景根本没走到那一步 -
json.RawMessage的字节切片共享 Decoder 底层 buffer，如果 decoder 被复用或 buffer 被覆盖，旧RawMessage会读到脏数据 - 循环中复用
itemstruct 时，记得在每次dec.Decode(&item)前手动清空 map/slice 字段，否则历史数据残留 - 不要用
strings.TrimSpace或bytes.Trim预处理整个文件——它们又把全文读进内存了
