Heritrix 评测：WARC 保真度与归档爬取的运营成本

Heritrix 是 Internet Archive 的开源归档爬虫——也是 Wayback Machine 背后的软件谱系，已经在生产环境中跑了二十年。它的任务是尽可能原汁原味地把网站实际返回的内容抓下来，写进 WARC 文件，这样多年后还能回放。它底层是一个 Java 引擎，每次爬取都用 XML 写成的 Spring bean 图来描述，整个任务生命周期则靠 REST API 来驱动。它不是数据抓取器：没有选择器语法，没有字段映射，也不会在最后给你一张表。

我用一个可控的本地测试环境对 3.16.0 做了实测，并逐条统计它真正写入了什么。最突出的特点就是完整：20 个被抓取的 URI 一共生成了 61 条 WARC 记录，而且每个响应都有 payload digest 和 capture IP，每个请求也都通过关联字段回连到对应响应；整个过程完全不需要碰任何配置开关。相对地，运维体验就完全是另一回事——解包后占 41 MB，带 114 个 jar 包（lib/ 里共有 142 个文件；另外 28 个是捆绑的 LICENSE 和 NOTICE 文本），在第一次抓取之前还要准备一份约 750 行的任务配置——不过本次所有爬取都通过 curl 无头完成，没有点过任何网页界面。

存储结果也暴露了一个不那么直观的默认行为。测试环境里有两个 URL 返回了逐字节完全相同的内容，但标准配置会把它们都完整抓取并归档：产生了两条 response 记录，0 条 revisit 记录，尽管两条响应的 payload digest 一模一样。只有在加入历史处理器之后，content-digest 去重才会生效；标准配置并不会启用它，而且它省的是存储空间，不是带宽。

Heritrix 到底是什么

归档不是网页抓取，这一点很值得先说清楚。Heritrix 不会直接给你表格，没有 CSV 结果。它输出的是 HTTP 会话本身——包括头部、正文和抓取元数据——并以一种为长期保存设计的格式存起来，它也是这一类工作的参考实现。让它给你导出产品价格表，就像让法庭速记员直接给摘要一样不合适。

截至 2026 年 7 月 27 日，这个仓库有 3,285 个 star、36 个 open issue，而 3.16.0 是最新发布版本，发布时间为 2026-07-03。我的测试用的正是这个版本，所以这里讨论的不是过时版本的遗留问题。许可证还有一点小插曲：LICENSE 文件本身是标准 Apache-2.0，但 GitHub 自己的检测结果显示为“Other”，因为部分捆绑的第三方文件带有各自的条款。如果 Heritrix 要进商业产品，这一点值得认真看上五分钟，而不是只扫一眼侧边栏徽标。

还有一个结构性事实决定了后面的所有差异：Heritrix 不会驱动浏览器。它通过 HTTP 拉取内容，并从返回字节中提取链接。它在现代归档领域的“兄弟”是 Browsertrix Crawler，路线正好相反——它运行真实的 Chromium，记录浏览器实际做了什么。两者都会写 WARC，但这篇评测只测了 Heritrix 的非浏览器路径；没有对任一系统的规模或吞吐量做基准测试。

链、bean 和 SURT：一次爬取到底是怎么拼起来的

在底层，Heritrix 的一个任务就是一个 Spring application context。不是“用 Spring 配置的”那种意思——它本身就是一张 Spring bean 图，写在 XML 里，爬取的每个部分都可以被替换成不同的 bean。

frontier 负责保存 URI 队列，并按主机分区。这个分区方式决定了礼貌抓取（politeness）为什么会以现在这种方式运作，后面还会再提到。

处理链 分三段完成工作：candidate chain（这个发现的 URI 要不要进入调度）、fetch chain（DNS、robots、HTTP 抓取、链接提取）以及 disposition chain（写入 WARC、更新状态）。给 Heritrix 增加能力，通常就是在正确的链上、正确的位置插入一个 processor bean；我把去重打开，就是这么做的。

scope 是一组基于 SURT 的 DecideRules 栈，SURT 即 Sort-friendly URI Reordering Transform，会把 http://www.example.com/a 重写成 http://(com,example,www,)/a，这样主机名前缀就能按层级排序。默认 scope 会根据 seed 的 SURT 前缀生成。规则按顺序依次接受或拒绝，最后一条匹配规则生效。

WARC writer 位于 disposition chain 中，而 politeness 则体现在 frontier 的三个参数里：delayFactor、minDelayMs、maxDelayMs。robots 遵从策略则是 fetcher 上的一个 policy 字符串。

而这一切都可以通过 REST API 驱动，这一点后来证明比我预想的还重要。

上手配置是整个体验里最重的一部分

在第一次抓取之前，你需要部署的内容如下：

这份任务配置里大多数内容你都不会去碰。但它又不能跳过，而且在爬虫开始抓取之前，有两个字段是必须填的：你的 seed，以及 metadata.operatorContactUrl。标准值只是占位符，不替换成一个能识别任务操作者的真实 URL，爬虫就不会开始。

这个要求带来了一个问责入口：操作者必须在启动前提供联系 URL。它并不能证明身份真实、抓取获得授权，或者符合适用规则，但至少把联系方式变成了任务的一部分，而不是可有可无的惯例。

有两个上手发现确实让我有些意外。

它能在比文档最低要求更高的 JDK 上运行。 Getting Started 文档 要求 Java 17 或更高。Heritrix 3.16.0 在 OpenJDK 26.0.1 上顺利启动、提供 REST API，并完成了这个测试环境里的所有爬取，没有用到 --add-opens、--enable-preview 或 Security Manager 方面的绕行方案。这只是一次 macOS arm64 上的结果，不是完整兼容矩阵，但至少说明这次测试的版本在这台机器上并不局限于 JDK 17。

你完全可以不用碰网页界面。 整个任务生命周期都能通过 REST 完成，我用 curl 把全流程自动化了：创建任务、PUT beans 文件、构建、启动、取消暂停、轮询直到 controller 状态变成 FINISHED、结束、清理。回答“Heritrix 能不能接入流水线”这个问题，答案就是：能，而且是无头运行，完全不需要点网页。很多文章会截 Jetty UI 的图，好像那就是唯一入口；其实它只是个方便项，不是必需品。

还有一条和机器环境相关的部署说明：这台 Mac 通过 Surge 全局接管了 HTTP 代理。Heritrix 的 Java client 继承了这个代理，甚至把 127.0.0.1 的本地测试流量也转了过去，结果即便 OS 里已经配置了例外列表和 NO_PROXY，还是返回了 503。用 -Djava.net.useSystemProxies=false 启动 JVM 后，结果从 2 次 503 变成了 18 次 200。这个问题是环境交互，不是 Heritrix 的缺陷；这个参数只在你不希望继承系统代理设置时才有意义。

实际进入归档的内容

我用标准默认配置跑了一个可控测试环境——本地服务器提供一组已知端点，包括 HTML 页面、三级深度链接链、robots.txt 和 sitemap，以及故意设置的 404 和 500 路由——然后不是看摘要行，而是逐条解析生成的 WARC 记录。

20 个被抓取的 URI 生成了 61 条记录：

这意味着每个 URI 都稳定保持了 1:1:1 的 response/request/metadata 比例，而且完全无需我额外配置。逐条检查后，完整性也站得住：

而 HTTP 状态也被原样保留了下来，包括那些不太好看的：200 OK、404 Not Found 和 500 Internal Server Error 都以真实状态行的形式出现在已存储的响应里，而不是被当成失败丢掉。

这一点比任何别的特性都更能把归档和网页抓取区分开。抓取器通常会把 500 当成要重试或跳过的错误；归档器则把它视为“服务器在那个时刻说了什么”，这是值得保留下来的事实。Heritrix Output 维基页面描述了这种记录结构；但我之前没见过的是针对一组已知端点的实测记录数量，以及 20/20 的关联完整性。结果确实如此。

去重结果：两种方式都测了

我的测试环境里，/dup/one 和 /dup/two 返回了字节级完全一致的正文。不同的 URL，同样的内容——这正是 content-digest 去重要折叠掉的场景。我跑了两遍：一次用标准配置，另一次是在插入 digest-history 链之后运行（BdbContentDigestHistory，再加上 fetch chain 里的 ContentDigestHistoryLoader 以及 WARC writer 之后的 ContentDigestHistoryStorer）。

开箱状态下，两条响应虽然拿到了相同的 digest，但没有任何历史处理器去利用它，所以两个正文都被完整写入。加入这条链之后，第二次抓取会变成一条 WARC revisit 记录，并指向相同的 payload digest，这正是 WARC 1.1 规范 对 revisit 的定义。

这并不是什么秘密。Duplication Reduction Processors 维基页已经明确写着 skipIdenticalDigests 的默认值是 false，且不依赖 URL 的去重需要这些 loader 和 storer bean。这里不是挖出了某种隐藏行为；和本次几乎所有测量一样，这些都是文档里已经有的 Heritrix 行为，只不过现在有了第一手数字。差别在于文档和人们“以为”的内容之间；按我的经验，大家通常会直接说“Heritrix 会去重”，后面不加任何配置前提。

有两个推论很值得记住：

去重发生在写入阶段，不会省带宽。 这一点我没有单独做流量计量，但原理很直接：只有字节到达之后才能计算并比较 digest，所以第二个 URL 还是得先从源站抓回来。启用这条链只会减少存储，而不会减少传输，也不会减少目标服务器实际要提供的内容。把去重当成礼貌抓取或带宽优化的人，理解方向正好反了。

指望“反正会去重”来估算存储，经常会严重失真。 如果你归档的是一个模板重复率很高的网站——比如镜像 PDF、带大量通用模板的落地页、同一篇文章的打印版——并且按“相同正文会自动折叠”来预估磁盘容量，那么标准配置实际占用的空间可能会明显高于这个估算。这个两 URL 测试只能证明默认行为，不代表百万 URI 规模下的效果；真正的效果取决于重复率、正文大小，以及是否会复抓。

Scope 和 robots 确实按它们承诺的那样工作

爬虫自己对“没抓到什么”的说法参考价值很有限，所以这两项都用服务器端命中计数来测：让目标服务器自己统计请求次数，不依赖 Heritrix 自己的日志。

Scope。 与此同时，scope 内的主机被正常抓取，所以这里表现出来的是纪律性，而不是爬虫坏掉了。需要说明一点：我这里只跑了默认 scope 这一侧，并没有做一个扩大 scope 的正向对照，因此请把它理解成对文档化设计的确认，而不是双向证明。

Robots。 链接本身始终是可达的；只有 robots 策略把它压住了。遵从是真的，绕行开关也是真的，这样才是正确的安排——有些归档任务在法律或制度上确实需要覆盖 robots，这种情况就应该通过在配置里明确写下 ignore 来完成，而不是默认悄悄越过。

礼貌抓取：抓 20 个本地页面花了 57.7 秒

有一个数字，基本就能决定 Heritrix 是否适合你的项目。

同一份测试环境、同样的三次运行处理、单一本地主机、亚毫秒级延迟：

实际延迟几乎完全落在 minDelayMs 的下限上：对于一个亚毫秒响应的来源站来说，delayFactor × fetch-time 几乎可以忽略，最终由最小值主导，这是设计使然。两行之间的比值并没有什么参考价值，因为关闭礼貌抓取时的分母只有几十毫秒，而且不同运行之间会有抖动。真正稳定的是绝对下限：在这个测试环境里，默认 Heritrix 在同一主机两次请求之间大约会等待 3 秒，把一个 20 页的爬取拉成了约 1 分钟。

更直观地算一笔账。假设某大学图书馆需要在一个政府网站下线前归档其 50,000 个页面，而这些页面都在同一主机上。按照 3 秒/主机的下限，光是强制等待就要 150,000 秒——大约 42 小时，也就是差不多一整天零十八小时，还没算抓取本身。这个数字来自我测出的 3,036 ms 下限：50,000 × 3.036 s = 151,800 s = 42.2 h；即便按配置里的 3,000 ms 最低值算，也是 41.7 小时，四舍五入就是 42 小时，不是 41 小时。这不是一次实际的百万级抓取，而是你的项目计划需要用到的算术。

公平地说，Heritrix 的礼貌抓取是按主机生效的，因为 frontier 本来就是按主机分队列的。跨成千上万个域名的大范围抓取，会在这些队列之间并行展开，不会把这个上限全局套到所有目标上。我的测试环境只有一台主机，这正是这个数字的最坏情况。如果你的归档目标是一个大站，那这个最坏情况就是你的现实情况。

而且这本来就是它的特性。这个延迟机制，正是让归档爬虫变成“站点所有者可以容忍，而不是直接封掉”的原因。把它调低，本质上是在替别人的服务器做决定；这款工具只是把这个决定明确地摆出来，而不是默认采取激进策略。

我没有测试的内容

这些测量只覆盖了可控测试环境中的爬取纪律，范围更大的一概不涉及。在边界之外的内容包括：

• 跨爬取去重和复抓。 我只测了单次爬取内的 content-digest 去重。跨独立爬取持久化 URI 历史数据库（FetchHistoryProcessor + PersistLog）是另一种机制，我没有跑。
• 规模和长期稳定性。 没有百万 URI frontier，没有 checkpoint 和恢复，也没有多日运行。我的测试主要衡量纪律性，不是耐久性。
• JavaScript 渲染抓取。 Heritrix 的默认捕获路径是非浏览器式的，我测的也是这个。可选的浏览器行为没有在这里测试。
• 高延迟源站上的礼貌抓取。 本地延迟是亚毫秒级，因此 minDelayMs 天然主导。delayFactor 在真实慢站上的放大效果没有被单独隔离出来。
• sitemap 召回率。 robots.txt 被请求了，sitemap 指令也被跟随了，但我没有逐条确认每个 <loc> 条目都被召回。

第一次正式任务前，哪些事情应该先说清楚

标准配置很长，但真正会改变归档含义的决策其实并不多。先从 scope 开始。seed 会生成默认的 SURT 前缀，而 DecideRules 可以按顺序把它们放宽或收紧。用代表性的 scope 内和 scope 外 URL 检查最终规则顺序，然后再用服务器端流量或其他独立请求日志验证。单靠爬取报告，无法证明某个被排除的主机从未被访问过。

接下来，要明确 robots 策略和操作者身份在这次采集中分别意味着什么。测试中的默认值会遵从测试环境里的禁止规则，而把 robotsPolicyName 改成 ignore 后，被禁止的路径就会被抓取。这个切换在机械上很简单，但在制度上很重要。请把是谁批准的、为什么批准的记录下来，同时保留一个有效的 operatorContactUrl；这个必填 URL 只是给站点所有者一个联系入口，并不能替代授权理由。

存储规划也需要单独做一个明确决定。如果你希望相同正文变成 revisit 记录，那就在估算归档大小之前先加入并检查 content-digest 历史处理器。我测试的这条链是在抓取之后改变表示方式，所以源站流量依然要按两个 URL 来预算。跨爬取去重是另一套机制，不能从这个两 URL、单次爬取的结果里直接推断出来。跑一个带已知重复正文的小验证爬取，是确认部署后的 bean 图确实产出了预期记录类型的低成本办法。

最后，把礼貌抓取当成调度输入，而不是临时调参项。在本地单主机测试环境里，minDelayMs 决定了总耗时。正式项目应该根据目标主机数量和采集截止时间来计算每主机下限，并在代表性延迟条件下进行测试。广域爬取和单站爬取对按主机分区的 frontier 施加的压力并不相同；这篇评测只测了后者。运行手册里也要保留 REST 生命周期：构建、启动、取消暂停、轮询、结束、清理，都是自动化中值得单独观察的状态。

优缺点

优点

• 默认归档完整性非常强：20/20 的响应都带有 payload digest、capture IP 和完整的 request↔response 关联，而且无需额外配置。
• 能把错误响应原样保留下来——200、404、500 状态行都按原样存储。
• 用服务器端计数验证了 scope 纪律：scope 外请求为 0，而 scope 内主机正常抓取。
• Robots 遵从会真正抑制抓取，而且如果确实需要强制归档，还有明确的 ignore 绕行开关。
• 完全可以无头通过 REST 运行——创建、构建、启动、轮询、清理，全都能用 curl 完成，不需要点 UI。
• 在 OpenJDK 26.0.1 上干净运行，不需要任何 JVM 标志；对一个二十年前的代码库来说，这已经是相当不错的现代 Java 兼容性了。
• 必填的操作者联系 URL 让爬虫不能匿名运行。
• 爬取的每个部分都是可替换 bean，所以启用去重只需要插入三个 bean，而不是分叉代码库。

缺点

• content-digest 去重默认关闭，重复正文会完整写入——这对存储规划是个真实陷阱。
• 部署很重：41 MB 的发布包、114 个 jar、一个 Java 引擎加 Jetty，以及一份约 750 行的 Spring 任务配置。
• 默认礼貌抓取会在每个主机上强制约 3 秒的下限；同主机 20 个 URI 的爬取用了 57.7 秒。
• 默认路径不做 JavaScript 渲染，所以纯前端渲染内容抓不到。
• 配置面很大，需要经验；没有那种“五分钟跑出第一个结果”的轻量路径。
• 输出里没有结构化字段。要从 WARC 中再提取字段，本身就是另一个项目。

谁适合用，谁该放弃

Heritrix 适合那些交付物就是档案本身的机构和团队。图书馆、国家档案馆、法律与合规保存、把网页作为一手资料来采集的研究团队，以及任何需要在五年后证明某个 URL 在某一天返回了什么的人。如果你的词汇表里已经有 “WARC”“replay”“provenance” 这些词，那这就是整个生态系统围着转的工具，而它的重量正是互操作性的代价。

它按主机分区的 frontier 和多年网页归档经验，使它也有理由成为跨多个域名的大范围爬取候选。这是架构层面和项目历史层面的判断，不是本测试环境里的规模结果；长期吞吐量、checkpoint 恢复以及百万 URI 行为，在这里都还没测。

如果你想要的是数据而不是档案，那就别用它。如果你的目标是产品、列表或联系人表格，Heritrix 会把页面抓得非常漂亮，但后面你还得自己再搭一整条解析管线——而且你为此支付的是一个 Java 引擎、一份 Spring 配置和每主机 3 秒的礼貌抓取下限。如果你的目标是客户端渲染的单页应用，也别用它；非浏览器抓取器只会抓到壳，抓不到内容，这种场景应该交给基于浏览器的归档工具。还有，如果你今天就要出第一个结果，也别选它，因为上手成本确实存在。

替代方案，以及托管 API 适合放在哪

在归档工具里，最直接的现代对应物是 Browsertrix Crawler——一个基于浏览器的归档器，会驱动 Chromium 并记录浏览器实际做过的事。它能捕获 Heritrix 默认 HTTP 响应中没有的 JavaScript 生成内容，但代价是要额外承担浏览器部署和运行开销。本评测没有做正面对比，所以选择应从捕获需求开始：如果需要浏览器生成的状态，那就选浏览器归档器；如果是传统 HTTP 资源，Heritrix 仍然是原生路线。

相关评测：Browsertrix Crawler 评测。

如果问题的形态完全不同——你要的不是档案，而是页面里的结构化数据——那就应该按输出结果来比较 Heritrix 和抽取系统，而不是把它们当成同类爬虫。Heritrix 是免费且自托管的：你负责 JVM、beans 文件、磁盘容量和礼貌抓取策略。这种模式适合交付物就是长期保存的场景。

免责声明：Thunderbit 是发布方自己的产品，本次 Heritrix 测试环境里并没有测试它。Thunderbit 属于托管抽取类别：它的输出是页面内容或结构化记录，而不是适合长期保存的 WARC 文件。当你需要可回放的抓取和来源证明时，应该选归档器；当你的交付物是表格行或文档文本，而且可以接受托管运行时，再考虑抽取服务。

归档还有它自己的授权问题，而且和网页抓取并不完全一样。Heritrix 默认遵守 robots.txt，并要求你在抓取任何字节前先表明身份，这已经是很好的基础；但遵守 robots 的爬取并不自动等于“获得授权”。版权、服务条款、个人数据，以及你所在机构自己的职责范围，都在它之上；ignore 策略是给有法律依据的机构使用的，不是方便开关。如果你要搭建归档项目，请在磁盘填满之前先把授权边界理清；如果这是新领域，也可以了解一下 web scraping 和 archiving 的法律问题。

试试 Thunderbit 进行网页数据提取

结论

要不要用 Heritrix？如果你的输出是档案，而且团队里有人愿意学习 Spring bean，那答案是：要。

这份测试环境给出了清晰结论：标准配置能稳定保留 response、request 和 capture metadata；scope 和 robots 控制会按配置影响服务器端请求；完整任务生命周期也可以通过 REST 跑通。对于一个小型、单主机边界内的归档流水线来说，这些都是很有价值的特性。

它的运营成本同样很明确：需要一个 Java 发布包和一大份 Spring 配置；本地抓取中，每主机的配置延迟是绝对主导；而 content-digest 去重还得额外加历史处理器。需要 WARC 保真度的团队可能愿意接受这些成本；需要抽取字段的团队则应该从别的类别开始。

在正式抓取之前，请先根据实际任务配置验证去重链、礼貌抓取设置、scope、robots 策略、操作者身份以及存储假设。标准配置只是起点，并不自动代表这些运行决策已经被明确选择。

试试 Thunderbit 进行网页数据提取 Get Started Free

常见问题

operatorContactUrl 会让抓取自动获得授权吗？ 不会。它只是强制任务包含一个联系 URL，给站点运营方一个问责入口，但并不能建立许可、证明身份真实、说明版权状态，或确保符合法规。这些仍然是爬虫之外的部署决策。

content-digest 去重会减少对源站的请求吗？ 在本次测试配置里不会。两个 URL 都已经先被抓取，之后才能比较 payload digest。历史链改变的是第二个 payload 在 WARC 存储中的表示方式，并不会把第二个 URL 变成被跳过的网络请求。

Heritrix 能在没有网页界面情况下运行吗？ 可以。测试中的完整生命周期——创建、上传配置、构建、启动、取消暂停、轮询、结束和清理——都是通过 REST API 和 curl 完成的。内置 Jetty UI 并不是必须的。

标准 Heritrix 配置会去重相同 payload 吗？ 在本次测试环境的当前配置下不会。标准配置把两个相同响应都作为完整 response 记录存了下来。加入 content-digest 历史链后，第二次抓取变成了 revisit 记录，所以去重是一个必须配置并验证的流水线选择，而不是自动默认行为。

我应该怎么选择礼貌抓取延迟？ 把这里的本地耗时当作机制检查，不要当作生产建议。延迟应根据目标站点规则、操作者协议、服务器容量、采集目的，以及你自己的重试/并发策略来设定，然后再在日志里确认实际的同主机请求间隔。