gjson不能用于大json文件的流式筛选，因其必须将整个json一次性加载进内存；真要流式处理应使用json.decoder配合json.rawmessage或megajson/scanner等第三方词法扫描器。
直接说结论：gjson 不能用于大 JSON 文件的流式筛选，它要求整个 JSON 字符串必须一次性加载进内存；真要流式处理，得用 json.Decoder 配合 json.RawMessage 或第三方词法扫描器（如 megajson/scanner）。
为什么 gjson 不适合大文件流式筛选
gjson.Get() 接收的是 []byte 或 string，底层会把整个 JSON 加载进内存做一次完整词法扫描——哪怕你只取 "data.items.0.id"，它也得先把几百 MB 的 JSON 全读进来。实测一个 80MB 的 JSON 文件，gjson.Get 调用后 RSS 内存飙升至 250MB+，远超原始体积。
这不是设计缺陷，而是定位决定的：gjson 是为「快速随机读取已加载 JSON」优化的，不是为「流式、低内存、边读边筛」设计的。
- 误用典型：
data, _ := os.ReadFile("big.json"); gjson.Get(data, "lang.en.title")—— 这和json.Unmarshal一样危险 - gjson 对 HTTP 流无效：无法传
http.Response.Body给它，没有io.Reader接口支持 - 不支持按条件提前终止：即使你只想找第一个匹配
"lang": "zh"的对象，它仍会扫完全文
真正能流式筛选语言学习数据的方案
语言学习数据常见结构是 NDJSON（每行一个 JSON 对象）或顶层为数组的巨型 JSON，目标常是「提取所有 lang == "ja" 的句子」或「替换 source_text 中的占位符」。这时必须放弃全量解析思路。
推荐组合：json.NewDecoder + json.RawMessage + 手动字段匹配：
- 对 NDJSON：直接
for dec.More() { dec.Decode(&item) }，每次只 decode 一行，内存恒定 - 对数组顶层：先
dec.Token()跳过'['，再用for dec.More() { dec.Decode(&item) }逐个读，避免分配底层数组 - 字段动态判断：用
map[string]json.RawMessage解析单个对象，再用json.Unmarshal(item["lang"], &lang)提取值，比反射快且可控 - 若只需字符串级替换（如把
"__WORD__"换成用户词），用megajson/scanner状态机扫描，全程不构建任何结构，内存占用
容易被忽略的细节：语言字段校验与编码安全
语言学习数据里常混入非标准字段（如 "lng"、"language_code"）、大小写混乱（"EN" vs "en"）、甚至 BOM 头或控制字符。这些在流式处理中不会自动报错，但会导致筛选漏项。
- 别依赖
strings.EqualFold(lang, "zh")就完事——先 trim 空格，再检查是否为空或含非法 UTF-8 字节（用utf8.Valid([]byte(lang))） - HTTP 响应若带
Content-Encoding: gzip，必须用gzip.NewReader(resp.Body)包一层再传给json.NewDecoder，否则invalid character ''错误会直接中断流 - NDJSON 文件开头若有空行或注释（如
// metadata），dec.Decode()会报invalid character；需用bufio.NewReader预跳过非 JSON 行，或用bytes.TrimLeft（仅限小文件）
流式处理的复杂点不在代码长度，而在状态边界：什么时候该跳过 token，什么时候该 abort 当前对象，什么时候该重置缓冲区——这些逻辑一旦漏掉，就会出现静默丢数据或卡死在 EOF 后的下一次 Decode。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
