不能直接用json.Unmarshal解析GB级JSON文件，因其必须将整个文件加载进内存再解析，易触发OOM；应使用json.Decoder配合Token()和Skip()流式处理，手动跳过无关结构，内存恒定在KB级。
为什么不能直接用 json.Unmarshal 解析几个 GB 的 JSON 文件
因为 json.Unmarshal 要求整个 JSON 文本加载进内存，再构建成 Go 结构体或 map[string]interface{}。一个 2GB 的 JSON 文件，实际内存占用往往超过 4GB——不是因为解析慢，而是根本跑不起来，直接触发 OOM kill。
常见错误现象：fatal error: runtime: out of memory 或进程被系统强制终止；即使文件只有几百 MB，嵌套深、字符串多时也极易爆内存。
- JSON 文件若为单一大对象（如
{"data": [...]}），json.Unmarshal会试图把整个data数组解成 slice，无法流式跳过无关字段 - 标准库
encoding/json提供了json.Decoder，但它默认仍需将每个 token 对应的值完整解码为 Go 值（比如把一整段长字符串读进string），对超大字段（如 base64 图片、日志正文）依然危险 - 真正需要的是“只解析路径，不加载值”，尤其是当你要提取
$.items.[0].metadata.name这类固定路径下的字符串，而忽略其余 99% 的内容
用 json.Decoder + 递归状态机跳过无关结构
核心思路不是“解析整个 JSON”，而是用 json.Token 流逐个读取 token，手动维护当前路径栈，仅在命中目标路径时读取对应值，其余一律跳过（decoder.Skip()）。
关键点在于：跳过数组和对象不能靠 `for` 循环读完所有元素，必须用 decoder.Skip()——它底层直接按括号/方括号匹配字节，不构造任何 Go 值，内存恒定 O(1)。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 递归函数本质是路径匹配器：输入当前期望的 key 名或数组索引，输入当前 token 类型，决定继续深入、提取值，还是调用
decoder.Skip() - 例如匹配
$.a.b[2].c：遇到"a"字符串 token → 进入对象；下一个 token 是"b"→ 继续；遇到[→ 进入数组；需跳过前两个元素（两次decoder.Skip()），再进入第三个元素对象 → 最后找"c" - 务必在每次调用
decoder.Token()后检查 error，网络流或截断文件会导致io.ErrUnexpectedEOF，不能忽略
如何安全提取字符串/数字而不触发内存暴涨
即使路径匹配成功，也不能直接调用 decoder.Decode(&v)——如果目标字段是几 MB 的 base64 字符串，Decode 仍会分配等长内存并拷贝。
正确做法是：用 decoder.Token() 拿到下一个 token，根据类型分别处理：
- 如果是
json.String：用decoder.Buffered()获取底层bytes.Buffer的快照，再用buf.Next(n)截取原始字节（避免字符串转换），或直接写入io.Writer（如文件、HTTP 响应） - 如果是
json.Number：调用token.(json.Number).String()得到字符串表示，但注意这会分配新字符串；如只需判断大小，可用int64或float64解码，但必须先确认数字范围（超int64会 panic） - 禁止对未知长度字段使用
json.RawMessage：它只是复制字节切片，不解决内存问题；且后续再解码仍要重入内存
真实场景中的坑：BOM、换行、非 UTF-8 和部分读取失败
生产环境的“超大 JSON”常来自日志导出或数据库 dump，往往带 BOM、混合换行（\r\n）、甚至局部编码错误。这些都会让 json.Decoder 在第一个 token 就报错。
- 务必用
bufio.NewReader包裹原始 reader，并调用reader.Discard(3)跳过 UTF-8 BOM（0xEF 0xBB 0xBF）；也可用strings.TrimPrefix(string(b), "\xef\xbb\xbf")预处理首块 - 换行不影响 JSON 解析，但某些 dump 工具会在每行加换行符（如 NDJSON 变体），此时不能用
json.Decoder直接读——要先按行分割，再对每行新建json.NewDecoder - 最易忽略的一点：目标路径可能根本不存在。递归函数必须有明确的 “not found” 返回路径，且不能因某次
decoder.Skip()失败就中断整个流——应捕获io.ErrUnexpectedEOF并返回，由上层决定是否继续下一段（比如文件含多个 JSON 对象）
递归深度本身不是问题（Go 默认栈足够深），但路径表达式若含动态索引（如 $.[*].id），就必须改用迭代+栈模拟，否则无法处理任意长度数组；纯静态路径（如 $.data.users[0].name）用递归最简洁，也最容易验证边界。
