jq JSON 流转换器

问题：当 JSON 不再是小玩具

日常开发中，我们习惯把 jq 当作处理小 JSON 文件的瑞士军刀——提取字段、过滤数组、重命名键，几十行的命令就能搞定。但当数据规模从 KB 跃升到 GB 级别时，事情就变了。

传统的 jq 处理方式需要先把整个输入解析成内存中的对象树，这意味着你的机器需要足够的 RAM 来容纳整个 JSON。遇到 5GB 的 NDJSON 日志流、持续生成的事件数据，或者嵌套极深的配置快照，jq 会直接崩溃，或者至少让你的终端卡死几分钟。

另一个痛点是：复杂转换的语法门槛。当你需要在流式数据上进行递归遍历、动态构造对象、或者执行归约操作时，手写正确的 jq 表达式变得相当棘手。括号匹配、管道组合、变量作用域，任何一个错误都可能导致难以调试的输出。

这个技能做了什么

jq JSON 流转换器 专门为这类场景设计。它的核心能力集中在两个层面：

1. 流式解析处理大文件

该技能利用 jq 的 --stream 参数，将传统的树形解析转换为事件流解析。这意味着：

• 内存占用恒定：无论输入是 100MB 还是 10GB，jq 只需要维护当前处理的路径和值，而不是整个对象树
• 实时处理能力：可以直接从 stdin 读取持续产生的 NDJSON，边接收边转换
• 递归下降支持：通过 path 和 getpath 操作，可以在不知道完整结构的情况下遍历任意深度的嵌套对象

2. 构建复杂的转换表达式

技能的另一半工作是帮你构造那些手写容易出错的 jq 过滤器：

• 对象构造：从流事件中重建结构化对象，比如把 {"path":"a.b.c","value":1} 还原成 {"a":{"b":{"c":1}}}
• 归约操作：使用 reduce 和 foreach 在流上聚合数据，比如统计所有深度为 3 的数组长度总和
• 递归下降：通过 recurse 和 .. 操作符处理任意深度的嵌套结构

适用边界与注意点

不要滥用流式模式：--stream 会显著改变数据的表示形式。原本 .foo.bar 这样的简洁路径，会变成 ["foo","bar"] 的数组形式。如果你的转换逻辑很简单，或者数据本身很小（<10MB），传统模式反而更直观。

性能权衡：流式解析的每一步都有固定的开销。对于深度很浅的 JSON，传统模式可能更快；流式模式的优势主要体现在深度大、数据量大的场景。

语法复杂度：复杂的转换逻辑（比如嵌套的 reduce + foreach）会增加调试难度。建议先用小样本数据验证表达式，再应用到生产流上。

内存与磁盘：虽然流式模式大幅降低了内存占用，但 jq 仍然需要临时存储中间结果（比如 --stream 模式下的数组）。处理超大文件时，建议配合 split 或管道缓冲，避免单次处理的数据块过大。