在 2026 年用查看器阅读 50MB JSONL 日志

在 2026 年用查看器阅读 50MB JSONL 日志

使用浏览器端的 JSONL 查看器，将每行解析为独立的 JSON 对象，并以可筛选、可排序的表格形式展示。这是阅读换行分隔日志最快的方式，无需编写临时脚本。粘贴文件即可生成列、筛选所需行并导出结果，无需在终端中折腾，也不会让 2GB 文件拖垮你的编辑器。所有处理均在客户端运行，因此支持离线使用。

下面链接的 jsonl 查看器是我自己搭建的。我已经厌倦了这种情况：今年春天我试过六款在线 JSON 工具，它们在粘贴换行分隔数据时都会卡住，因为它们都假设输入是单个 JSON 文档，而 JSONL 其实是一系列独立的 JSON 对象。我的工具完全在浏览器中运行，无需注册、无需上传，任何数据都不会离开你的机器，而且免费。如果你有更好的方案，欢迎告诉我。

让我的文本编辑器崩溃的日志文件

上周二凌晨两点左右，我正在排查生产环境中的超时问题。唯一能找到的证据是一份已流式写入磁盘的 NDJSON 日志：340 MB，大约 120 万行，每行一个 JSON 对象。我首先尝试在编辑器中打开它。编辑器思考了很久，风扇开始狂转，然后窗口变白并停止响应。真酷。

于是我改用 jq。jq 'select(.level == "error")' app.log 确实能用，而且 jq 本身是个很棒的工具，但我不记得确切的字段名，过滤条件总是写错，每次猜错都得从头重新读取整个文件。二十多分钟后我仍未看到一行数据。错误其实出在第 811,406 行，但我当时并不知道。我只是想先了解数据结构，再决定如何筛选。这就是差距所在。

JSONL（也叫 NDJSON 或 JSON Lines，不同名称指同一概念）是一系列 JSON 值，每行一个。日志流水线喜欢它，因为可以追加行而无需重写整个文件，写入过程中崩溃也只会丢失最后一行。问题是大多数 JSON 工具都假设输入是单个文档，因此读取你的 120 万行后，会在遇到第二个 { 时立刻报错。

JSONL 查看器如何解析对象流

JSONL 查看器的核心逻辑其实非常简单：按换行符拆分，对非空行逐行解析。关键技巧在于不让某一行解析失败导致整个渲染崩溃，因此需要对每行单独捕获错误并继续。

// Split, drop blanks, parse each line independently.
function parseJSONL(text) {
  return text
    .split('\n')
    .filter((line) => line.trim() !== '')
    .map((line, i) => {
      try {
        return { ok: true, row: JSON.parse(line) };
      } catch (err) {
        return { ok: false, line: i + 1, raw: line, error: err.message };
      }
    });
}

const sample = `{"ts":"2026-04-11T02:14:03Z","level":"error","msg":"timeout","ms":9812}
{"ts":"2026-04-11T02:14:04Z","level":"info","msg":"retry","attempt":2}
not valid json
{"ts":"2026-04-11T02:14:06Z","level":"info","msg":"ok"}`;

console.log(parseJSONL(sample));

Enter fullscreen mode Exit fullscreen mode

运行后会得到四条结果。其中三行成功解析为对象，not valid json 那行则返回 { ok: false, line: 3, ... }，而不会让其他三行一起失败。查看器会把这个数组中的所有键合并成列（ts、level、msg、ms、attempt），然后渲染成表格。此时 level 就成了可以直接筛选的列，而不再是需要用 grep 搜索的字符串。

你无需自己实现这些逻辑。把文件粘贴到 JSONL viewer 中，它就会在浏览器里完成上述操作，并为你提供一个可排序、可筛选的表格，同时用红色标记出损坏的行，让你能发现数据损坏，而不是默默丢弃这些行。这种红色标记功能其实是我用得最多的功能——我一半的「Bug 报告」最终都指向某条被截断的日志行。

表格真正能为你带来什么

解析只是简单的一半。表格优于纯文本的原因在于你可以在其上执行的操作。我几乎总是先进行筛选：在 level 列输入 error，120 万行就会缩减到仅剩 3000 行。然后我按时间戳排序，找到第一条错误，因为第一条错误通常才是真正的根源，其余都是连锁反应。

对数值字段（如以毫秒为单位的耗时）进行排序，正是表格发挥作用的地方。在编辑器里我只能手动查看数字，而在这里我只需点击 ms 表头，最慢的请求就会排到最前面。上周这帮我发现了一个 14,203 毫秒的异常值，如果只靠滚动浏览，我永远不会注意到它，而这正是整个 Bug 的所在。

导出功能完成了整个闭环。筛选出我关心的行后，我可以将其导出为 JSON 或 CSV，并将这个切片放入工单，这样接手的人看到的只有 40 行相关数据，而不是一个 340 MB 的文件和一个耸肩。

jq、电子表格与文本编辑器的对比

每种工具都有其适用场景。下面是我实际选择它们的方式：

在探索阶段、尚未明确需要查找什么时，查看器胜出。当我已知确切查询并希望将其放入脚本或管道时，jq 更合适。我在 CI 中使用 jq，而在凌晨两点大脑半离线时使用查看器。不同场景不同工具，我不再为同时使用两者而感到内疚。

何时不应该使用它

我自己搭建了这款工具，但仍然不会在所有场景下使用它。以下是一些诚实的限制。

如果文件确实非常巨大（数 GB），请继续使用 jq 或流式解析器。浏览器标签页有内存上限，加载 3 GB 的数据到表格中会和卡住编辑器一样让页面挂起。查看器适用于编辑器已力不从心，但数据仍能放入内存的范围，大致是几百 MB 以内。

如果任务是自动化的，查看器就完全不合适。任何按计划运行或在构建过程中执行的操作都应该使用 jq 或小型脚本。人类点击网页的操作不应该出现在 cron 任务中，如果你尝试这么做，维护起来会非常痛苦。

如果处理的是深层嵌套对象，扁平表格很快就会变得尴尬。查看器会尽量展平数据，并将嵌套对象显示为可折叠的 JSON 块，这虽然可读，但并非魔法。对于重度嵌套场景，我仍会回到 jq 的路径表达式。没有工具能赢下每一局，假装它可以只会让你在凌晨两点用错工具。

常见问题

问：JSONL 和 NDJSON 是同一回事吗？
答：实质上是的。JSONL、NDJSON 和 JSON Lines 都指同一种格式：每行一个 JSON 值，用 \n 分隔。在尾随换行和空行等细节上可能存在一些学术上的差异，但任何像样的查看器都会把这三种名称视为同一格式处理。

问：我的数据会被上传到其他地方吗？
答：不会。解析过程完全在浏览器客户端运行，因此文件永远不会离开你的机器。这正是我采用这种方式的全部原因。我不想把生产日志粘贴到别人的服务器上，然后祈祷一切顺利。

问：它实际能处理多大的文件？
答：这更多取决于你可用的内存。我曾在普通笔记本上顺利处理过 90 MB 的文件。超过几百 MB 你会感觉到标签页变重，这时就该切换到 jq 了。

问：我可以导出筛选后的行吗？
答：可以。一旦你缩小到需要的行，就可以将可见集合导出为 JSON 或 CSV，这对于把干净的切片交给同事而不是原始转储非常有用。

问：为什么不直接全程使用 jq？
答：你可以这样做，而且很多人都在这么做。我喜欢用 jq 处理已知查询和管道。查看器则用于更混乱的阶段——在那时我还不知道字段名，也不知道自己在找什么，只是想用眼睛去探索数据。

由 AI 辅助撰写并经人工审阅。工具体验地址：aidevhub.io/jsonl-viewer。