今年备受关注的抓取工具，大多都想驱动浏览器运行。而 trafilatura 不走这条路。它是一个纯 Python 库，专门读取静态 HTML，判断哪些区块才是真正的正文，其余内容一律丢掉。它只做这一件事——提取主内容——而这正是它从“LLM-ready markdown”这个说法还没流行时就一直在做的事。
我在 Python 3.14 上，用一组固定的测试样本跑了 2.1.0 版本，其中最让我印象深刻的，是文章抽取测试。我把一段真实正文包进常见的页面杂项里——登录提示、“Subscribe”订阅提醒、导航链接、版权页脚——结果 trafilatura 一次调用就把标题、正文三段、作者和日期全都提了出来，而且所有这些模板化内容都被清理得一干二净。没有浏览器，没有按站点写规则，只有一个函数调用。只是，它也有自己的边界；当你要求它输出结构化数据时，这个限制马上就会显现。下面我会展开说，这不是缺陷，而是设计取舍。
trafilatura 是什么，以及你最好放下的一个假设
官方简介把它称为“一个用于从 Web 获取文本和元数据的 Python 与命令行工具：涵盖抓取、爬取、抽取”，并支持 CSV、JSON、HTML、Markdown、TXT 或 XML 输出。这个描述覆盖面很广，但也掩盖了它真正的差异化所在。它的价值不在爬取辅助功能，也不在那六种输出格式，而在于内容抽取：输入 HTML 文档，输出正文文本，同时剥离页面杂项。
换个更容易理解的方式来看，它的工作逻辑正好解释了它的优势和边界。大多数你拿去处理网页的爬虫，都是“选择器驱动”的：你告诉它“抓取 class 为 product-price 的元素”，它就把那个地址里的内容返回给你。trafilatura 走的是反方向。它会把整篇文档读一遍，然后自己判断哪些区块是正文、哪些是模板噪音，靠的是内容启发式规则，而不是你手写的选择器。也正因为这样，它在面对你从没见过的网站时，不需要任何站点级配置就能把页面清理干净。可也正因为如此，它没法直接返回结构化目录：没有 schema，没有字段映射，只有对“哪些算内容”的判断。它是提取器，不是你随手指向就能解析成表格的爬虫。
它还真的很轻量。纯 Python，不用无头浏览器，不会在缓存里塞一个 Chromium 二进制，也没有第一次运行就跳出来的 Playwright 安装包。单看这些似乎没什么，但当你要对成千上万条 URL 做抽取时，每一份依赖、每一个子进程都意味着运维成本。这是一个大约 6.26k stars 的项目（截至 2026-07-09，见 adbar/trafilatura），比它常被拿来一起比较的浏览器框架和爬虫框架要小得多；这反映的是它的定位，不是在贬低它的质量。
安装部分很短，而这本身就是优点
安装只需一行命令，而且几乎没什么可提醒你的，这一点本身就值得写进评测。pip install trafilatura 在一个全新的 virtualenv 里，把 Python 3.14 上需要的包干净利落地装好了——没有浏览器要下载，没有后置安装步骤，也没有一长串让人头疼的传递依赖。类似的库我见得够多了，通常都会等着第二只靴子落地：第一次执行时才冒出来的 150MB 浏览器包、编译不过的原生扩展、别人从没提过的额外 [fetchers] 依赖组。可在 trafilatura 这里，那只靴子压根没掉下来。
pip 给我的版本是 2.1.0，和当前发布版一致，而当前版本发布时间是 2026-06-07，所以下面所有数字都不是“你测的是旧版”那种过时结果。这个类别里很多更重的工具，等我真正跑起来时早就落后一个大版本了；而这里测试版和正式发布版完全一致。
实测：这个提取器到底返回了什么
我用一组测试样本来验证 trafilatura，既覆盖它擅长的场景，也覆盖它的边界。最后决定我对它看法的，是文章抽取测试。
我拿了一个本地文章样本，把真实正文埋进各种噪音里——登录提示、“Subscribe”号召、导航链接、版权页脚——这正是朴素爬虫最容易连正文一起抓回来的那类模板内容。结果 trafilatura 返回了标题和三段正文，三段一个没少；而所有独立的模板标记——Login、Subscribe、Copyright——都没有出现在输出里。除了文本，它还准确提取了页面元数据中的作者和日期。一次调用就同时输出了 .txt、.md 和 .json。
这个多格式输出值得单独说一下。一次提取同时生成了纯文本、Markdown 和 JSON。Markdown 这条路径，正是大家现在都在追求的“LLM-ready 文本”步骤：把脏网页喂进去，拿到保留结构的干净内容，然后交给模型处理。trafilatura 完成这件事时，整个流程里根本没有浏览器介入，这是一条更安静、更省事的路线，却能得到和浏览器驱动工具差不多的结果。
接着看公开测试。我把它指向一个真实产品页——Books to Scrape 的商品页——它返回了 1,324 个字符的干净文本和 Markdown：描述块清晰可读，周围没有页面杂项。再把它喂给一个返回 HTTP 500 的页面时，fetch_url 返回的是 None，而不是直接抛异常。不中断、不崩溃、不留一堆堆栈信息，这种平静但正确的失败方式，恰恰是排程任务里最需要的。
需要注意的地方
一共有三点，每一点都会限定它适合的场景。
第一点，也是最重要的一点：trafilatura 是内容提取器，不是结构化爬虫。我用一个 12 个商品的目录样本测试过，它确实返回了 12 个商品名——但只是文本——以及 0 条结构化记录（478 个字符的平铺文本）。名称和价格都在输出里，只是它们不是字段。如果你需要的是 [{name, price, rating}, …] 这种结果，这就不是合适的工具，而且没有任何配置项能把它变成那样。这是设计上的取舍，不是个该提的 bug。
第二点：它不会渲染 JavaScript。它只消费静态 HTML。如果你把它指向一个客户端渲染的单页应用，拿到的只会是 JS 执行前服务器返回的那份内容，而那通常没什么用。若目标站点大量依赖 JS，你需要自己配一个渲染器；trafilatura 不负责这半边，也从来没有这样宣称过。
第三点，是对我自己证据的一点说明。上面那个公开提取测试依赖的是商品描述块，而不是真正的新闻文章，因为我使用的公开沙盒（toscrape 这一类）全是目录页，没有新闻页面。真正“清理文章”的结果来自一个受控的本地样本。我相信这个结果——因为模板清除非常明确，也完全可复现——但商品页并不能证明它具备新闻编辑室级别的抽取能力，所以我不会把它写成那样。
为了稍微补上这个空白，我另外做了一个不计分的演示，选了两篇真实文章页面，并读取已保存的 fixture，确保运行结果可复现。在 Wikipedia 的“Web scraping”文章上，trafilatura 把页面从 230,049 字节的原始 HTML 缩减到 26,673 字节的提取内容（正文/原始比为 0.116），而我检查的四个页面杂项标记——“Jump to content”“Privacy policy”“Powered by MediaWiki”“This page was last edited”——全部被去掉了。在一篇存档的 Wikinews 文章上，它从 79,716 字节降到 2,200 字节（比率 0.028），我检查的五个标记也全部消失。两篇页面都正确返回了标题、日期和 hostname；但作者和站点名都为空，我也如实写出来，不会刻意掩盖。这里要分清两件事：这个字节比例衡量的是被剥离掉了多少 HTML 和页面杂项，不是抽取准确率；而且这两页都来自同一 MediaWiki 家族，所以这只是一个真实文章的演示，不是具有代表性的语料库。
至于准确率，我不假装自己已经做过全面基准测试，而是引用外部证据。trafilatura 自己提供了一个 evaluation page，并且在 ScrapingHub article-extraction benchmark 里，以大约 0.945 的 F1 位居开源工具前列，超过了 readability-lxml（约 0.887）等对比项。关于这个数字，我要诚实说明两点：它来自那个基准测试，而不是我自己的测试；并且文档里报告的约 0.945，是和较旧的 0.5.1 版本关联的，不是我实际测试的 2.1.0。把它当作外部证据，说明这个工具为什么在抽取领域有口碑，而不是把它当成这篇评测里的实测结果。
优点与缺点
优点：
- 在我测试的样本里，文章抽取效果最干净——标题加 3/3 段正文全部保留，Login/Subscribe/Copyright 等模板标记全部清除。
- 能连同正文一起准确提取作者和日期元数据。
- 一次调用可输出多种格式：txt、Markdown、JSON——其中 Markdown 真的很适合作为 LLM-ready 文本输入。
- 轻量、纯 Python 安装，不需要浏览器、无需下载二进制文件，也没有沉重的依赖墙。
- 失败处理很稳：遇到 HTTP 500 时，
fetch_url返回None而不是抛异常。 - 测试版本就是当前发布版（2.1.0），不存在版本偏差。
- Apache-2.0 许可，宽松且适合商用。
缺点：
- 不是结构化爬虫：目录测试返回了 12 个名称文本，却没有任何带类型的行。没有 schema，也没有字段。
- 不支持 JavaScript 渲染——只能处理静态 HTML；如果页面依赖客户端渲染，需要另配渲染器。
- 某些站点的元数据不完整：我在两个真实文章样本里都拿到了空的 author 和 sitename。
- 我做的公开文本测试依赖的是商品描述块，不是真正的新闻文章。
- 内置的爬取/sitemap spider 和 CSV/XML 输出格式在这次测试中都没有覆盖，因此我不对它们下结论。
它适合谁，不适合谁
trafilatura 非常适合这样的人：你手里有一堆 URL，想要的是干净的文章正文，不想看到导航栏、cookie 横幅和订阅弹窗。建文本语料、把网页喂给模型、归档可读内容、对网页文章做 NLP——这些都是它最擅长的场景。如果你想要一个轻量、无需浏览器的步骤，把杂乱 HTML 变成干净的 Markdown 或 JSON，那就装上它，继续做你的事。
但如果你真正需要的是结构化抽取，比如带价格的商品行、类型化记录、key: value 字段，那就别选它。它给你的是文本，不是表格；目录测试已经证明它只能拿到名称，拿不到行结构，这点不会改变。如果目标网站的内容要等浏览器渲染后才出现，而你又不想自己再接一个渲染器，那也别选它，因为 trafilatura 只读静态 HTML，读完就停。它的失败方式不夸张，只是结果空空或很薄，让你一时摸不清原因。工具要和任务匹配——文章正文，它很行；结构化 JSON 或 JS 渲染页面，就换别的方案。
替代方案，以及 Thunderbit 在哪里
先把公平的前提说清楚。trafilatura 是一个免费、Apache-2.0 许可、可自托管的库，你自己运行它，代码归你，按页调用也没有成本，而且足够轻，可以直接塞进任何数据管道，不会带来太多运维负担。就“把文章剥离成干净文本”这个任务来说，这种组合几乎很难被打败，付费服务也不会改变这个结论。
真正有意义的比较，出现在 trafilatura 故意划出的边界上：结构化数据和 JavaScript。这两件事它都不做，而这恰好是托管抽取 API 最擅长接手的部分。Thunderbit 的开发者栈就站在这条线的另一侧——它不是和 trafilatura 在静态 HTML 文章文本上竞争，而是补上 trafilatura 刻意不做的那半边。/distill 端点做的事情，和 trafilatura 的工作形态很像：把页面提炼成干净、适合 LLM 的 Markdown；区别在于，JavaScript 渲染由服务端完成，这正是 trafilatura 跳过的部分。/extract 则能按照你定义的 schema 返回结构化 JSON，这正好是 trafilatura 因设计而拒绝的能力：前面那个目录页在 trafilatura 里只拿到 478 字符的平铺文本，而在这里你会更想用 /extract。如果你面向 AI agents 或编码助手，还有一个 MCP server，里面的字段建议工具可以免费试用；终端、CI 和 cron 场景则可以直接用 npx @thunderbit/thunderbit-cli。它运行在同一套引擎上，也就是被 10 万多人使用的 Thunderbit Chrome Extension，所以非技术路线当然也存在。不过对这类读者来说，更相关的是 API、MCP 和 CLI。
所以，真正的取舍从来都不是“谁的文本抽取得更好”——在它擅长的页面上，trafilatura 确实更强，这点我会直接说。取舍在于范围，以及谁来跑浏览器。你要的是从静态 HTML 中提取干净文章正文、自己托管、零单页调用成本？那 trafilatura 就是更轻、更锋利的工具，没什么好争论的。你要的是按照 schema 输出结构化 JSON，或者页面必须等 JavaScript 运行后才会出现内容？那就是托管方案的战场，而不是 trafilatura 想参与的比拼。如果你要衡量托管侧的成本，可以去看 Thunderbit pricing page，把每页成本和自己维护渲染器的成本放在一起算。
如果你想横向比较整个类别，我一直在维护一份 我实际在用的网页抓取工具 对比清单，会把这类库和浏览器驱动、托管方案放在一起看。
结论
要不要用 trafilatura？要——如果你的任务是把杂乱 HTML 变成干净的文章正文，而且你清楚它有两件事不会做。它只用一个轻量安装、没有浏览器介入，就把页面里的所有模板噪音都清掉了，同时返回标题、三段正文、作者和日期。它还能同时输出 txt、Markdown 和 JSON，这让它成为一个合格的 LLM-ready 文本处理步骤。在一个大家都以为“没有无头浏览器和 AI 爬虫就什么也做不了”的领域里，这个根本不打开浏览器的工具，反而把我最在意的清理工作做得很好。
只是要把它定位正确。它是提取器，不是结构化爬虫——目录页只给了 12 个名称文本和 0 行结构化数据。它只读静态 HTML，不运行 JavaScript。它的元数据提取在某些页面上很强，在另一些页面上则只完成了一半（我检查的两个真实文章样本里，author 和 sitename 都是空的）。而且我做的公开文本测试依赖的是商品描述块，不是真正的新闻文章，所以关于“适用于新闻编辑室级别抽取”的说法，应该先看成有潜力，而不是已经盖棺定论。只要在这些边界内，trafilatura 就能比我对比过的更重型工具更干净地完成它唯一擅长的事情——而且几乎不用安装什么东西。
试试 Thunderbit 做网页数据提取 Get Started Free
常见问题
trafilatura 实际会从网页里提取什么？ 它提取的是正文主内容——包括文章主体、标题，以及作者和日期等元数据——同时去掉模板噪音。在我的测试里，它把一个包着导航栏、登录、订阅和版权内容的页面，提取出了标题和 3/3 段正文，而且这些标记一个都没出现在输出里。它通过启发式规则判断哪些算正文，因此无需为从没见过的页面单独写选择器。
trafilatura 能把商品目录抓成结构化行吗？ 不能。它是内容提取器，不是结构化爬虫。在一个 12 商品目录样本上，它只返回了 12 个商品名称的平铺文本（478 个字符），没有任何结构化行——名称虽然在输出里，但并不是字段。如果你需要 name/price/rating 这类类型化记录，请用基于选择器的解析器，或者 schema 驱动的抽取 API。
trafilatura 会渲染 JavaScript 吗？ 不会。它只处理静态 HTML。把它指向客户端渲染的页面时，拿到的只是 JavaScript 执行前服务器返回的内容，而那通常不是你真正要的。若目标站点大量依赖 JS，请配一个单独的渲染器；trafilatura 只负责读取静态文档，然后就结束。
trafilatura 安装起来麻烦吗？
不麻烦——这正是它真正的卖点之一。pip install trafilatura 在 Python 3.14 的全新 virtualenv 里，干净地装下了整套包，没有浏览器下载、没有后置步骤，也没有隐藏的 extras 组。pip 装上的版本是 2.1.0，和 2026-06-07 发布的当前版本一致。
和其他提取器相比，trafilatura 的准确率怎么样？ 这篇评测里我没有专门做准确率基准测试，所以这里引用外部证据。trafilatura 自己提供了 evaluation page，并且在 ScrapingHub article-extraction benchmark 里，以大约 0.945 的开源 F1 领先于 readability-lxml（约 0.887）等对比项。需要注意的是，这个数字来自那个基准测试，而且对应的是较旧的 0.5.1 版本线，不是我测试的 2.1.0——所以把它看作工具口碑的外部证据，而不是这篇文章里的实测结果。
