根据 2025 年开源现状报告，去年有 96% 的组织增加或维持了对开源软件的使用——而“没有许可成本”仍然是最主要的原因。但有件事，很多人从 GitHub 上随手拿一个爬虫工具时都不会被提醒：“开源” 和 “可以安全用于商业产品” 其实不是一回事。
今年我花了不少时间梳理常见热门项目——Scrapy、Playwright、Puppeteer，以及更新一些的 AI 原生爬虫，比如 Crawl4AI 和 ScrapeGraphAI——而真正影响企业决策的关键，往往并不会出现在常规“最佳爬虫榜单”里：许可证类型。大多数榜单只看 GitHub stars，我则更看重法务团队问出“等等，这个是 AGPL 吗？”之后会发生什么。下面这份清单先按适用场景分类（解析器、浏览器自动化、AI 原生爬虫、抓取框架、无代码扩展），再看许可证，因为现实中的决策顺序就是这样。
为什么许可证类型是筛选开源网页爬虫的第一道门槛
“开源”并不等于“想怎么用就怎么用”。开放源代码定义明确禁止对商业用途进行歧视——所以这份清单里的每个工具都允许商用。但你能如何使用它，以及发布时要承担什么义务，完全取决于具体许可证。
宽松型许可证——MIT、BSD-3-Clause、Apache-2.0——只要保留版权声明，几乎可以随便用。Apache-2.0 还额外包含明确的专利授权，所以往往更受法务欢迎。这三种都不要求你公开自己的源码。
而传染性更强的许可证就完全不同了。AGPL-3.0 是最容易让人踩坑的那一种，而 Firecrawl 的自托管核心正是采用这个许可证（SDK 是 MIT，但核心爬取引擎是 AGPL）。根据 AGPL-3.0 第 13 节，如果你修改了受其约束的程序，并通过网络让用户与这个修改版交互，就必须向他们提供对应源码。这并不是很多论坛上说的那种“整个 SaaS 都会被强制开源”的简单结论——义务具体针对的是修改过的受约束程序，且是以远程交互方式提供给用户。但如果你打算在上面做闭源商业产品，这已经是一个值得认真咨询律师的问题，而不是刷刷 Stack Overflow 就能解决的。
还有一种更模糊的“开源核心 + 商业增值”模式。Web Scraper 这个 Chrome 扩展在 GitHub 上确实有一个历史上的 LGPL-3.0 仓库，但该仓库最后一次代码提交停留在 2017 年，而且目前没有经过验证的证据能说明那份旧源码和 Chrome Web Store 里现在的扩展版本（本文写作时为 1.111.13）一一对应。更诚实的说法是：本地扩展本身是免费的，而包含定时任务和代理轮换的 Cloud 版本则是单独的专有产品；如果把整个项目都说成“开源”，就会把这个分层给掩盖掉。
我们是如何比较这 12 款最佳开源网页爬虫工具的
我从七个维度来评估每个工具：许可证类型与商用摩擦、语言/运行环境、原生 JavaScript 渲染支持（还是需要外挂插件）、上手难度、隐藏的计算或代理成本、社区健康度信号（开放 issue、发布频率、最近一次提交），以及最适合的使用场景。
这份列表按类别分组——静态解析器、浏览器自动化框架、AI 原生爬虫、抓取框架，最后是那个无代码浏览器扩展——而不是单纯按 star 数排序。这是有意为之。Beautiful Soup 和 Scrapy 解决的是完全不同的问题，虽然它们都很受欢迎；把它们放在同一条线上比较，并不能真正帮助任何人做选择。
| 评估维度 | 我查看的内容 |
|---|---|
| 许可证与商用适配 | 仓库的实际许可证、署名要求、传染性/网络条款 |
| 运行环境与团队适配 | Python、Node/TypeScript、Java 或多语言支持 |
| JS 渲染 | 原生浏览器支持、插件配合，还是完全不支持 |
| 框架范围 | 仅解析器、浏览器驱动器、完整抓取管线，还是托管产品 |
| 社区健康度 | GitHub stars、最新发布日期、开放 issue、最近一次 push |
| 隐藏成本 | 浏览器内存、代理需求、模型 API 依赖、维护负担 |
| 最佳适配场景 | 结合文档能力或 issue 记录，判断具体团队/任务匹配度 |
关于社区健康度数据，这里有个必须说明的例外：Beautiful Soup 的官方开发主要在 Launchpad 上进行，不是在 GitHub 上，所以它的 GitHub star 数（作为非官方镜像目前为 223 星，且最后更新是 2022 年）无法和另外 10 个工具直接比较。下面我会明确标注这一点，而不是假装它能整齐地塞进同一张表里。
静态网站最佳开源解析库：BeautifulSoup
BeautifulSoup 是一个 Python 库，用于浏览和搜索 HTML/XML 解析树。它不负责抓取页面、不执行 JavaScript，也不管理抓取队列——它只负责处理你已经拿到的标记内容，并提供一个很友好的 API 让你从中提取数据。它的范围之所以这么窄，正是它存在的意义：当你已经拿到 HTML，只需要把数据挖出来时，它就是最趁手的工具。
- 许可证： MIT——非常宽松，除了保留声明外几乎没有额外义务
- 上手难度： 真的适合新手；对象模型很宽容
- JS 渲染： 原生不支持；需要先搭配别的工具抓取渲染后的 HTML
- 已知限制： 官方文档明确承认 它“永远不会比底层解析器更快”，而不同解析后端（lxml、html5lib、html.parser）在处理不规范 HTML 时，生成的树结构可能会有明显差异
最适合： 快速内部脚本，以及一次性的静态页面或已获取 HTML 的数据提取——不适合规模化，也不适合大量 JS 页面。
旧系统跨浏览器测试最佳开源浏览器自动化框架：Selenium
Selenium 是这份清单里资历最老的名字，最初是为浏览器测试而生，后来被半个爬虫圈拿来继续用。它最突出的特点不是速度，而是覆盖面。官方 Selenium 4 绑定支持 Java、Python、C#、Ruby 和 JavaScript，并通过 W3C WebDriver 标准驱动 Chrome、Edge、Firefox 和 Safari。
- 许可证： Apache-2.0
- GitHub 健康度： 34,366 stars，98 个开放 issue，过去一年有 12 个稳定版本发布（最新：4.47.0）
- JS 渲染： 原生支持，通过真实浏览器执行
- 文档中的摩擦点： Selenium 自己的文档把同步问题称为“最常见的挑战之一”——页面加载完成并不代表 JS 动态注入的元素也准备好了，DOM 动态刷新还会让你遇到
StaleElementReferenceException
最适合： 需要多浏览器或多语言覆盖的团队，或者本来就在用 Selenium 做 QA，希望复用同一套技能来做抓取。
现代 JS 重度网站最佳开源浏览器自动化框架：Playwright
Playwright 由 Microsoft 维护，是对“Selenuim 用起来太慢、太笨重”的现代回应。它原生自动化 Chromium、Firefox 和 WebKit，并带有可操作性检查：在真正可交互之前，会自动等待元素满足可见、稳定、启用等条件。光是这个自动等待机制，就省掉了 Selenium 用户手写的大量 WebDriverWait 样板代码。
这里有个经常在“Scrapy vs. Playwright vs. Selenium”讨论里被忽略的细节：Scrapy 本身不会渲染 JavaScript。它必须外挂一个单独的插件——scrapy-playwright——才能获得浏览器渲染能力。而 Playwright 和 Puppeteer 是原生渲染，因为渲染本身就是它们的产品能力。
- 许可证： Apache-2.0
- GitHub 健康度： 94,443 stars，过去一年有 15 个稳定版本发布（最新：1.62.1）
- 隐藏成本： 仅浏览器二进制文件就大约需要 Chromium 281 MB、Firefox 187 MB、WebKit 180 MB——而且 1.38 的破坏性变更停止了自动下载浏览器，因此 Docker 镜像版本锁定非常重要
最适合： 抓取 React/Vue 单页应用、并且需要稳定跨浏览器行为而不想自己手写等待逻辑的团队。
Chrome 重点项目最佳开源浏览器自动化工具：Puppeteer
Puppeteer 是 Google 自家的自动化库，天生以 Chrome 为核心——深度集成 Chrome DevTools Protocol，内置截图/PDF 生成等功能。这里有个需要纠正的旧认知：现在的 Puppeteer 也正式支持稳定版 Firefox，所以“只支持 Chrome”已经不完全准确了，尽管 Chrome 仍然是主要使用场景。
- 许可证： Apache-2.0
- GitHub 健康度： 95,458 stars，249 个开放 issue——开放 issue 数明显高于 Playwright，如果你很在意响应速度，这一点值得纳入考量
- 反爬现实： Puppeteer issue #7006 记录了一个完全正常的导航请求却被 Cloudflare challenge 拦下的案例——这说明渲染页面并不等于绕过反爬系统，事实就是如此
最适合： 已经标准化到 Chrome 的 Node.js 团队，尤其是既要抓取又要生成 PDF/截图的场景。
面向 LLM 和 RAG 流水线的最佳开源 AI 原生爬虫：Crawl4AI
Crawl4AI 底层使用 Playwright，但它是专门为 LLM 和 RAG 流水线输出干净 Markdown 而设计的，而不是输出一堆原始 HTML。它既支持“干净 Markdown”模式，也支持针对上下文窗口优化的 “Fit Markdown” 模式；如果你愿意，还能启用可选的 LLM 提取。即使完全不碰模型 API，CSS/XPath 和 BM25 过滤也照样能用。
这里有一点需要特别准确地说明：GitHub 页面把这个仓库标成 Apache-2.0，但 实际许可证文件 额外加入了一个要求：公开使用和分发时必须署名。这并不是原生 Apache-2.0，而是 Apache-2.0 加上项目自定义条件；真正要看的应当是许可证文件，而不是 GitHub 侧栏的徽标。
- GitHub 健康度： 77,959 stars，最新版本 v0.9.2（2026 年 7 月）
- 资源要求： 自托管指南 建议容器至少预留 4 GB 内存
- 已知不稳定性： v0.9.0 更新日志记录了 Docker-server 认证默认值的破坏性变更，以及模块迁移——这是一个变化很快的项目，版本最好锁定
最适合： 需要把新鲜网页数据喂给 LLM agent 或 RAG 流水线、并且能自行承担浏览器基础设施的 Python 团队。
面向自托管部署的最佳开源 AI 原生爬虫（但有许可证门槛）：Firecrawl
Firecrawl 的自托管核心 把 AGPL 讨论变得非常具体。它是一个 API-first 的爬虫，能返回 Markdown、HTML、截图和结构化数据——能力确实很强，底层建立在 Fetch 和 Playwright 上。但大家提到“Firecrawl”时常联想到的那部分精致体验——托管式反反爬处理、代理轮换、Fire-engine 隐身层——实际上属于 Firecrawl Cloud，而不是自托管仓库本身。Firecrawl 的自托管文档 也明确写着：Fire-engine 和高级反反爬行为不包含在默认的自托管栈里，截图和页面动作都需要它。
- 许可证： 核心主要是 AGPL-3.0-or-later，SDK 为 MIT
- GitHub 健康度： 166,527 stars——这个类别里确实非常夸张的高
- 部署现实： 自托管意味着你要部署 Redis、RabbitMQ、PostgreSQL，必要时还要加 FoundationDB——这不是单容器项目，而是多服务系统
最适合： 内部工具或能接受 AGPL 源码提供义务的开源项目。若要在此基础上构建闭源商业产品，务必先做法律审查。
用自然语言提取内容的最佳开源 AI 原生爬虫：ScrapeGraphAI
ScrapeGraphAI 让你直接用自然语言描述需求，而不是自己写选择器——它是一个基于图的流水线，由 LLM 调用来完成字段映射。这个 MIT 许可的库使用的是你自己的基础设施：你自己的 LLM API Key（或者如果你想省 token 费用，也可以用本地 Ollama 模型），以及你自己配置好的 Playwright 实例。
但这里有个必须明确说明的代价：“开源”并不等于“零持续成本”。每次提取都会消耗你接入模型的 token。并且，提示词驱动提取有一个选择器方案没有的问题：某个开放 issue 记录了这样一种情况：管线每一步都显示成功，但最终返回的字段却是空值/NA，而页面上其实明明有数据——这种静默失败是确定性的 CSS/XPath 工具通常不会出现的。
- 许可证： MIT
- GitHub 健康度： 29,447 stars，最新稳定版 v2.1.6
最适合： 非规则、一次性的提取任务，前提是你愿意用模型成本和验证开销来换取提示词灵活性。
轻量级、无需模型的最佳开源 AI 原生爬虫：AutoScraper
AutoScraper 完全绕过了 LLM。你只需要提供一个 URL 和一个示例值，它会自动从页面中推断结构规则，并将这些规则复用到相似页面上。没有模型 API Key，没有 token 账单——底层就是 requests 和 BeautifulSoup。
不过要小心论坛里常有人给它贴上的“项目已废弃”标签，这并不准确。它在 2025 年年中确实还有实际提交，仓库最后一次 push 也发生在 2026 年 7 月。但用户真正用 pip install 安装到的打包版本仍是 2022 年的 v1.1.14。更准确的说法是“发布节奏很慢”，而不是“项目已死”。
- 许可证： MIT
- GitHub 健康度： 7,844 stars
- 硬限制： 不支持原生 JS 渲染——它直接调用
requests.get()，拿到什么 HTML 就解析什么，别无选择
最适合： 规模小、重复性强、页面结构稳定的静态抓取任务；页面改版后你也愿意偶尔重新训练规则。
大规模 Python 项目的最佳开源抓取框架：Scrapy
Scrapy 是生产级 Python 抓取框架——引擎、调度器、下载器、Item pipeline，一应俱全。如果 Beautiful Soup 是手术刀，那 Scrapy 就是整间手术室：异步网络、按域并发控制、AutoThrottle，以及可直接导出为 CSV、JSON、JSON Lines、XML 或云存储的导出器。
前面提到的那个关键区别在这里再强调一次，因为它也是 Scrapy 最容易被误解的地方：Scrapy 没有原生 JavaScript 渲染。Scrapy 官方文档 的建议是先找出并复现底层数据请求——因为这通常比整页浏览器渲染更快、更完整——只有在浏览器真的不可避免时，才使用 scrapy-playwright。
- 许可证： BSD-3-Clause
- GitHub 健康度： 63,830 stars，304 个开放 issue，过去一年有 9 个稳定版本发布（最新：2.17.0）
- 限速短板： 一个 开放增强请求 指出，AutoThrottle 是根据延迟而不是 HTTP 429 响应来调节的——基于响应状态的退避逻辑，还得你自己实现
最适合： 大规模静态站点抓取，且你更看重结构化管线和导出灵活性，而不是 JS 渲染。
Node.js 生产级项目最佳开源抓取框架：Crawlee
Crawlee 来自 Apify 团队，可以看作是 Node/TypeScript 世界里最接近 Scrapy 的对应物——只不过它不是后来再把 JavaScript 渲染硬塞进去，而是从一开始就在共享的队列、存储和代理轮换层之上，内建了基于 Playwright 和 Puppeteer 的爬虫类。
- 许可证： Apache-2.0
- GitHub 健康度： 25,364 stars，过去一年有 8 个稳定版本发布（最新：3.18.1）
- 聪明之处： 它的
AutoscaledPool会根据实时 CPU、内存和事件循环负载 动态调整并发，而文档也明确警告，最低并发设得过高会让整个抓取任务崩掉
最适合： 想要生产级队列管理和 JS 渲染，但又不想自己拼装 Scrapy 同类组件的 Node.js/TypeScript 团队。
企业级 Java 索引场景最佳开源抓取框架：Apache Nutch
Apache Nutch 是这份清单里的异类——一个为大规模网页索引而生的 Java 爬虫，通常会把数据送入 Solr、Elasticsearch 或 OpenSearch。它不是用来从竞品网站抓商品价格的；它是企业搜索团队在搭建搜索索引底层抓取层时会用的工具。
- 许可证： Apache-2.0
- GitHub 健康度： 只有 3,276 stars，但最近一次 push 仍是在 2026 年 8 月——星数少只是因为它是非常细分的领域，不代表项目冷清
- JS 处理： 需要单独的
protocol-selenium插件；一条 JIRA 记录 还专门记录了这个插件路径下的 HTTPS 代理失败问题
最适合： 已经在运行 Java/Hadoop 基础设施、并且需要企业级网页索引，而不是临时数据提取的团队。
最佳无代码浏览器扩展：Web Scraper
Web Scraper 是点选式方案——一个内置在 Chrome DevTools 里的站点地图和选择器树构建器。它可以处理分页、点击按钮、滚动无限加载页面，并且无需写代码就能本地导出为 CSV/XLSX。
这里的“开源核心 + 商业扩展”分层，比这份清单里的任何地方都更值得注意。本地抓取确实免费。但定时自动化、云端执行、API 访问和代理管理都放在 Web Scraper Cloud 里，那是一个单独收费的产品。而前面也提到过，公开可见的 LGPL-3.0 源码仓库自 2017 年后就没有新的代码提交了——所以“开源”更应该被理解为本地扩展的历史来源，而不是对今天 Chrome Web Store 版本透明度的保证。
最适合： 偶尔做本地提取的个人或小团队，不想写代码，也不需要规模化能力。
静态解析器 vs. 无头浏览器：如何为 JS 重度网站选对工具
有个数据值得先摆出来：98.9% 的网站都使用 JavaScript 作为客户端语言。但这组数据经常被误读成“98.9% 的网站都需要无头浏览器来抓取”——其实不是。它测量的是 JavaScript 的存在，不是你的目标数据到底是在初始 HTML 里，还是必须等脚本执行后才会出现。
这一区别才是真正的决策点。把这 12 个工具分成两个更诚实的桶：
静态解析器——BeautifulSoup、AutoScraper——速度快、成本低，但对客户端渲染的内容完全视而不见。如果你需要的数据就在初始 HTML 响应里，或者可以直接调用到 JSON 接口，那么这类工具在速度和简洁性上永远占优。
无头浏览器框架——Playwright、Puppeteer、Selenium、Crawlee 的浏览器爬虫——是真的会执行 JavaScript，因此会消耗真实计算资源。HTTP Archive 2024 数据 显示，中位数页面在移动端的 JavaScript 负载为 558 KB，且包含 22 个独立 JS 请求——这就是无头浏览器每次加载页面都要处理的工作量，而静态解析器只需要拿到原始 HTML 就行。
Scrapy 也处在一个值得再说一次的中间位置：它既不是这个，也不是那个。它是完整抓取框架，但没有原生渲染；如果你需要 JS，就必须外挂 scrapy-playwright。
“免费”的隐藏成本：代理、计算资源与维护时间
许可证价格为零，只是总成本中的一个输入项，不是全部。我会把真实成本拆成几个更具体的部分：
计算资源。 规模化运行无头浏览器，付费的不是“服务器时间”这么简单，而是“浏览器秒数”。AWS Fargate 的 Linux/x86 计费大约是每 vCPU-秒 $0.000011244、每 GB-秒 $0.000001235——把这个乘上你同时运行的 Playwright 实例数，费用会比很多人预期得快得多。
代理。 Bright Data 的公开价格 显示，住宅代理大约从 $5/GB 起，数据中心代理从 $0.9/IP 起——而这些计费模型里的“带宽”包含请求和响应两部分，不只是你下载的数据。这就是最容易让团队措手不及的一项：规避限流和封禁并不免费，它会持续出现在你的基础设施预算里。
维护。 这份清单里的每一个静态解析器和结构规则工具，都会因为网站改版而让选择器失效。AutoScraper 自己的 README 示例，目标站点一改版，就得更新价格规则。这就是“隐藏计算/代理成本”里最容易被 $0 许可证标签掩盖的部分——真正耗掉的，是你工程师修复失效提取逻辑的时间。
对于那些总是卡在这些问题上的团队——选择器频繁失效、代理账号管理、永无止境的 DevOps 负担——当把工程师时间也算进去后，自托管开源栈未必比你想象中更便宜。Thunderbit 的 Chrome 扩展 则给非开发者提供了另一种思路：把它指向一个你有权限访问的页面，点击 One Click Extract，它会自动分析页面，判断该提什么数据——不用写选择器，页面布局变动后也不需要维护脚本。它并不是 Scrapy 这种抓取框架级别的替代品，但如果你一直在手工维护一套脆弱的 AutoScraper 规则，它就是一个合理的下一步。
决策框架：如何根据团队约束匹配合适工具
多数对比文章写到“某工具最适合 X 场景”就结束了。但这只是一个变量。实际工作里，团队至少同时要考虑四个维度：是否需要 JS 渲染 × 团队语言栈 × 需要的输出格式 × 许可证约束。
| 团队情况 | 最合适的工具 | 原因 |
|---|---|---|
| Python、静态 HTML、快速脚本 | BeautifulSoup、AutoScraper | 不需要 JS、MIT 许可证、配置最少 |
| Python、大规模结构化抓取 | Scrapy | BSD-3-Clause，自带管线；只有真的需要 JS 时才搭配 scrapy-playwright |
| Node/TypeScript、带 JS 的生产抓取 | Crawlee | Apache-2.0，队列系统原生内建浏览器支持 |
| 多语言、广泛浏览器矩阵 | Selenium | Apache-2.0，语言和浏览器覆盖最广 |
| 现代 SPA 自动化、跨浏览器 | Playwright | Apache-2.0，原生渲染，内置自动等待 |
| 面向 Chrome 的自动化并包含截图/PDF | Puppeteer | Apache-2.0，CDP 集成很深 |
| LLM/RAG Markdown 流水线 | Crawl4AI | Apache-2.0 + 署名条款；要看法务是否能接受附加条件 |
| 基于提示词的非规则提取 | ScrapeGraphAI | MIT，但要预留 LLM token 成本 |
| 自托管、API 对齐、可接受 AGPL | Firecrawl | AGPL-3.0-or-later；在基于它构建闭源 SaaS 前先让法务确认 |
| 企业 Java/Hadoop 索引 | Apache Nutch | Apache-2.0，专为搜索基础设施而生 |
| 无代码、偶尔使用、非开发者 | Web Scraper 扩展 | 本地免费；先理解开源核心与商业版本的分层 |
横向对比这 12 款开源网页爬虫工具
| 工具 | 语言 | 许可证 | 商用是否安全 | JS 渲染 | 上手难度 | 最适合 |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ 是 | 不支持（需搭配） | 低 | 静态 HTML 解析 |
| Selenium | 多语言 | Apache-2.0 | ✅ 是 | 原生支持 | 中 | 多浏览器/多语言测试到抓取 |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ 是 | 原生支持 | 中 | 现代 JS 重度网站 |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ 是 | 原生支持 | 中 | 以 Chrome 为中心的自动化 |
| Crawl4AI | Python | Apache-2.0 + 署名条款 | ⚠️ 需审查条款 | 原生支持（经 Playwright） | 中 | LLM/RAG Markdown 流水线 |
| Firecrawl（自托管） | TypeScript | AGPL-3.0-or-later（核心） | ⚠️ 有条件 | 原生支持（经 Playwright） | 高（多服务） | 自托管 AI 抓取，且能接受 AGPL |
| ScrapeGraphAI | Python | MIT | ✅ 是 | 原生支持（经 Playwright） | 中 | 自然语言提取 |
| AutoScraper | Python | MIT | ✅ 是 | 不支持 | 低 | 轻量级、重复性静态任务 |
| Scrapy | Python | BSD-3-Clause | ✅ 是 | 需要配合 | 高 | 大规模静态站点抓取 |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ 是 | 原生支持 | 中 | Node.js 生产级爬虫 |
| Apache Nutch | Java | Apache-2.0 | ✅ 是 | 需要插件 | 高 | 企业搜索索引 |
| Web Scraper（扩展） | 不适用（无代码） | 开源核心+商业版本 | ⚠️ 视版本而定 | 原生支持（真实浏览器） | 低 | 非开发者偶尔使用 |
结论：你到底该用哪一个开源网页爬虫？
这里没有单一的“最佳工具”——正确答案取决于你的许可证约束、团队语言栈，以及目标数据是在静态 HTML 中，还是被 JavaScript 挡在后面。Scrapy 适合大规模 Python 静态抓取；当 JS 渲染不可妥协时，Playwright 或 Crawlee 更合适；如果你要给 LLM 流水线喂数据，Crawl4AI 是一个不错的选择，但要注意它的许可证文件里还有额外的署名条款，最好先看一眼。Firecrawl 的自托管核心功能很强，但 AGPL 这件事需要法务参与，而不是跳过。
如果你发现自己在选择器维护和代理管理上花掉的工程时间，已经比真正抓数据的时间还多，那通常就是一个信号：该考虑像 Thunderbit 这样的无代码替代方案了，而不是继续往自托管 OSS 栈上叠更多层。
关于开源网页爬虫工具的常见问题
用开源网页爬虫工具收集商业数据合法吗？
一般来说，抓取公开可访问的数据，风险通常低于抓取登录后或付费墙后的内容，但这并不意味着在任何场景下都自动合法。请始终检查目标网站的服务条款和 robots.txt 文件——不过要注意，robots.txt 只是请求协议，不是授权机制，遵守它是好习惯，但它本身并不提供法律授权。即便数据是公开可见的，GDPR 之类的数据隐私法规也同样适用。这不是法律意见——只要不是非常轻量、低频的使用场景，建议咨询律师。
“开源”是否意味着可以免费用于商业用途？
从某种意义上说，是的，因为 开放源代码定义 禁止许可证歧视商业用途。但“可以商用”和“没有附加义务”是两回事——AGPL-3.0（Firecrawl 自托管核心使用的许可证）允许商用，但如果你提供的是修改过的版本并且通过网络对外提供，就仍然需要提供相应源码。MIT、BSD 和 Apache-2.0 则没有这种要求。
开源爬虫和无代码抓取工具有什么区别？
Scrapy、Playwright、BeautifulSoup 这类开源爬虫，需要你自己写代码、管理基础设施，并处理抓取逻辑、代理和导出等问题。像 Web Scraper Chrome 扩展或 Thunderbit 浏览器扩展这样的无代码工具，则通过可视化界面或 AI 驱动的页面分析来处理字段识别和提取，用一定灵活性换来更低的上手门槛。
哪款开源网页爬虫最适合非开发者？
这份清单里的大多数工具——Scrapy、Playwright、Puppeteer、Crawlee 等——默认都假设你会写代码。对非技术用户来说，Web Scraper Chrome 扩展提供了点选式配置，但它的定时和云功能在付费层后面。如果你希望不用碰选择器就能自动识别字段，像 Thunderbit 浏览器扩展这样的智能无代码工具会是更实用的起点。
为什么 Scrapy 需要单独的插件来渲染 JavaScript？
Scrapy 的设计是以 HTTP 为先——它发请求，然后解析返回的 HTML，不执行任何客户端脚本。这种架构让它在静态网站抓取中非常快、非常轻，但也意味着 JavaScript 渲染出来的内容根本不会出现在它收到的响应里。scrapy-playwright 通过在必须渲染时把特定请求路由到真正的 Playwright 浏览器实例，弥补了这个缺口。
了解更多
