根據 2025 年開源現況報告 顯示，去年有 96% 的組織增加或維持了對開源的使用量，而「沒有授權成本」依然是最主要的原因。不過，有一件事很少人會先提醒你：當你從 GitHub 下載一個爬蟲工具時，「開源」和「可安全用於商業產品」其實不是同一件事。
我今年花了不少時間整理常見工具——像是 Scrapy、Playwright、Puppeteer，以及較新的 AI 原生爬取工具如 Crawl4AI 和 ScrapeGraphAI——而真正會影響商業決策的關鍵，往往不會出現在一般「最佳爬蟲工具」榜單裡：那就是授權類型。多數清單只按 GitHub stars 排名；但我更在意的是，當法務問一句「等等，這是 AGPL 嗎？」時會發生什麼事。這份清單先依類別適配度排序（解析器、瀏覽器自動化、AI 原生爬蟲、爬取框架、無程式碼擴充功能），再看授權，因為實務上的決策順序本來就是這樣。
為什麼授權類型是任何開源網頁爬蟲的第一道篩選條件
「開源」不等於「你可以隨便拿來用」。開源定義 明確禁止歧視商業用途，因此這份清單中的每個工具都允許商用；但你被允許怎麼使用、以及在發布產品時要承擔哪些義務，完全取決於具體授權條款。
寬鬆授權——MIT、BSD-3-Clause、Apache-2.0——幾乎可以讓你做任何事，只要保留版權聲明即可。Apache-2.0 還多了明確的專利授權條款，這也是律師通常最喜歡的一種。這三者都不要求你公開自己的原始碼。
Copyleft 授權就不一樣了。AGPL-3.0 是最容易讓人踩雷的一種，而它正是 Firecrawl 自架核心 所採用的授權（SDK 是 MIT，但核心爬取引擎是 AGPL）。根據 AGPL-3.0 第 13 條，如果你修改了受授權的程式，並讓使用者透過網路與修改後的版本互動，你就必須提供對應原始碼。這並不是網路論壇常說的那種「整個 SaaS 都會變成開源」；義務只針對「被修改過、且供遠端互動的受授權程式」。但在你把它建立成封閉原始碼產品之前，這確實是一個需要正式法律意見的問題，不是看一篇 Stack Overflow 回答就能解決的。
再來是比較模糊的「open-core」類型。Chrome 擴充功能 Web Scraper 在 GitHub 上有一個歷史上的 LGPL-3.0 倉庫——但那個倉庫最後一次程式提交是在 2017 年，而且目前無法驗證那份舊原始碼與 Chrome Web Store 中現行擴充功能（截至本文撰寫時版本為 1.111.13）之間的對應關係。比較誠實的說法是：本機擴充功能是免費的，但具排程與代理輪換功能的雲端版本是另一個專有產品；若把整體都稱為「開源」，就會掩蓋這個差異。
我們如何比較這 12 款最佳開源網頁爬蟲工具
我從七個面向評估每個工具：授權類型與商用摩擦、語言/執行環境、是否原生支援 JavaScript 渲染（還是需要外掛搭配）、學習曲線、隱藏的運算或代理成本、社群健康指標（未解決問題數、發版頻率、最後提交時間），以及最適合的使用情境。
這份清單是依類別分組——靜態解析器、瀏覽器自動化框架、AI 原生爬蟲、爬取框架，最後是那一個無程式碼瀏覽器擴充功能——而不是單純依 stars 數量排序。這是刻意的選擇。Beautiful Soup 和 Scrapy 解決的是完全不同的問題，即便兩者都非常熱門；把它們放在同一條軸線上排名，其實幫不了任何人選工具。
| 評估項目 | 我檢查的內容 |
|---|---|
| 授權與商用適配 | 倉庫的具體授權、標註要求、copyleft/網路條款 |
| 執行環境與團隊匹配 | Python、Node/TypeScript、Java，或多語言支援 |
| JS 渲染 | 原生瀏覽器支援、外掛搭配，或完全不支援 |
| 框架範圍 | 解析器、瀏覽器驅動、完整爬取流程，或代管產品 |
| 社群健康 | GitHub stars、最新 release 日期、未解決問題、最後 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 顆星、98 個未解決問題、過去一年 12 次穩定版發佈（最新：4.47.0）
- JS 渲染： 原生支援，透過真實瀏覽器執行
- 文件中明載的痛點： Selenium 自己的文件把同步問題列為「最常見的挑戰之一」——文件載入完成不代表 JS 動態插入的元素也已就緒，而 DOM 一旦刷新，就可能拋出
StaleElementReferenceException
適合用於： 需要多瀏覽器或多語言覆蓋的團隊，或原本就用 Selenium 做 QA、想直接沿用技能來做爬取的團隊。
最適合現代 JS 重度網站的開源瀏覽器自動化框架：Playwright
由 Microsoft 維護的 Playwright，可以視為「Selenium 太慢、太繁瑣」的現代解法。它原生支援 Chromium、Firefox 與 WebKit，並透過可操作性檢查自動等待元素真的準備好——可見、穩定、可啟用——再進行互動。光是這種自動等待機制，就能省掉很多 Selenium 使用者手寫的 WebDriverWait 樣板程式。
有一個常被「Scrapy vs. Playwright vs. Selenium」討論串忽略的細節：Scrapy 本身不會渲染 JavaScript。如果要有瀏覽器渲染，必須額外接上 scrapy-playwright 這類外掛。Playwright 和 Puppeteer 能原生渲染，是因為「渲染」本身就是它們的核心功能。
- 授權： Apache-2.0
- GitHub 健康度： 94,443 顆星，過去一年 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 顆星、249 個未解決問題——未解決問題數明顯比 Playwright 高，如果你很在意回應速度，這點值得納入考量
- 反機器人現實檢查： Puppeteer issue #7006 記錄了一個非常正常的導覽流程卻被 Cloudflare 挑戰攔下的案例——換句話說，能渲染頁面不代表你就對反機器人系統隱形了
適合用於： 已標準化在 Chrome 的 Node.js 團隊，尤其是需要在爬取之外同步產生 PDF/截圖的場景。
最適合 LLM 與 RAG 流程的開源 AI 原生爬蟲：Crawl4AI
Crawl4AI 內部是 Playwright，專門為 LLM 與 RAG 流程輸出乾淨的 Markdown，而不是原始 HTML 雜訊。它同時支援「clean Markdown」與針對上下文視窗優化的「Fit Markdown」模式；如果你需要，也可使用選配的 LLM 擷取。不過，CSS/XPath 與 BM25 篩選也能在完全不碰模型 API 的情況下運作。
有一點需要精準指出：GitHub 雖然把這個倉庫標示為 Apache-2.0，但 實際授權檔案 另外加了一條對公開使用與散布的強制標註要求。這不是標準的 Apache-2.0，而是 Apache-2.0 加上專案特定條件；真正該看的不是 GitHub 側欄徽章，而是實際授權檔。
- GitHub 健康度： 77,959 顆星，最新版本 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 顆星——在這個類別裡非常驚人
- 部署現實： 自架代表你要搭起 Redis、RabbitMQ、PostgreSQL，必要時還有 FoundationDB——這是多服務架構，不是一個容器就能搞定
適合用於： 願意接受 AGPL 原始碼提供義務的內部工具或開源專案。在沒有法務審核前，別急著直接拿它的自架核心來做封閉原始碼商用產品。
最適合自然語言擷取的開源 AI 原生爬蟲：ScrapeGraphAI
ScrapeGraphAI 讓你用自然語言描述想要什麼，而不是自己寫 selector——它是一個以圖為基礎的流程，透過 LLM 呼叫來處理欄位對映。這個 MIT 授權的函式庫使用的是你自己的基礎設施：你自己的 LLM API key（如果你想避開 token 費用，也可以用本地 Ollama 模型），以及你自己設定好的 Playwright 實例。
這裡要明講一個代價：「開源」不代表「沒有持續成本」。每次擷取都會依你接上的模型消耗 token。而 prompt 驅動的擷取有一種 selector 型工具不太會有的失敗模式：有一個 未解決問題 顯示流程每一步都成功完成，但對於頁面上明明存在的資料，最後卻回傳空值/NA——這種靜默失敗，使用決定性的 CSS/XPath 通常不會發生。
- 授權： MIT
- GitHub 健康度： 29,447 顆星，最新穩定版 v2.1.6
適合用於： 不固定、一次性的擷取任務，當 prompt 的彈性比模型成本與驗證成本更重要時。
最適合輕量、無模型依賴擷取的開源 AI 原生爬蟲：AutoScraper
AutoScraper 完全跳過 LLM。你只要提供一個 URL 和想擷取的範例值，它就會從頁面推斷結構規則，並把這些規則重用到相似頁面上。沒有模型 API key，沒有 token 帳單——底層就是 requests 和 BeautifulSoup。
要小心一些論壇常把它貼上的「已經被放生」標籤。這其實不準確：2025 年中仍有實際提交，倉庫最後一次 push 也在 2026 年 7 月。不過，讀者實際會安裝的套件版本仍是 v1.1.14，也就是 2022 年的版本。比較公平的描述是「套件發佈節奏慢」，而不是「專案已死」。
- 授權： MIT
- GitHub 健康度： 7,844 顆星
- 明確限制： 不支援原生 JavaScript 渲染——它只會呼叫
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 顆星、304 個未解決問題、過去一年 9 次穩定版發佈（最新：2.17.0）
- 限速落差： 一個 未解決的增強需求 指出 AutoThrottle 是根據延遲而不是 HTTP 429 回應來調整，因此要對回應做感知式退避，還得你自己來實作
適合用於： 大規模靜態網站爬取，當你更重視結構化流程與匯出彈性，而不是 JS 渲染時。
最適合 Node.js 生產環境的開源爬取框架：Crawlee
來自 Apify 團隊的 Crawlee，可說是最接近 Scrapy 的 Node/TypeScript 對應方案——差別在於 JavaScript 渲染不是事後補上的，而是一開始就透過 Playwright 與 Puppeteer 支援的 crawler 類別，搭配共享的佇列、儲存與代理輪換層來完成。
- 授權： Apache-2.0
- GitHub 健康度： 25,364 顆星，過去一年 8 次穩定版發佈（最新：3.18.1）
- 聰明細節： 它的
AutoscaledPool會依即時 CPU、記憶體與 event loop 負載 動態調整併發——而文件也明確提醒，若把最小併發設得太高，整個爬取流程可能直接崩潰
適合用於： 想要生產級佇列管理與 JS 渲染、又不想自己拼湊出 Scrapy 等級元件的 Node.js/TypeScript 團隊。
最適合企業 Java 索引的開源爬取框架：Apache Nutch
Apache Nutch 是這份清單中的異類——它是一個為大規模網路索引打造的 Java 爬蟲，通常會將資料送往 Solr、Elasticsearch 或 OpenSearch。它不是你拿來抓競爭對手商品價格的工具；它是企業搜尋團隊在建立搜尋索引底層爬取層時會選的工具。
- 授權： Apache-2.0
- GitHub 健康度： 只有 3,276 顆星，但直到 2026 年 8 月仍有提交——低 stars 反映的是利基領域，而不是專案怠惰
- JS 處理： 需要額外的
protocol-selenium外掛；一個 JIRA ticket 記錄了在這條外掛路徑下發生的 HTTPS proxy 失敗
適合用於： 已經運行 Java/Hadoop 基礎架構、且需要企業級網頁索引而非臨時資料擷取的團隊。
最適合無程式碼操作的開源瀏覽器擴充功能：Web Scraper
Web Scraper 是點選式方案——一個內建於 Chrome DevTools 的 sitemap 與 selector 樹建立器。它可以追蹤分頁、點按按鈕、捲動無限載入頁面，並將結果本機匯出為 CSV/XLSX，全程不需要寫任何程式。
這裡的 open-core 分裂，幾乎比這份清單中的任何工具都更值得注意。本機擷取真的免費；但排程自動化、雲端執行、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。
「免費」的隱藏成本：代理、運算與維護工時
零授權費只是總成本的一個輸入項，不是全部。我會把真實成本拆成幾個具體區塊：
運算成本。 大規模跑無頭瀏覽器，付的是 browser-seconds，不只是伺服器時間。AWS Fargate 對 Linux/x86 大約收取每 vCPU-second $0.000011244、每 GB-second $0.000001235——把這個數字乘上你同時跑的 Playwright 實例數，成本累積比很多人想得快得多。
代理成本。 Bright Data 公開的價格 顯示，住宅代理起價約為 $5/GB，資料中心代理從 $0.9/IP 起——而這些計價模式中的「頻寬」包含請求與回應的 payload，不只是你下載的內容。這正是最容易讓團隊措手不及的一筆：避免 rate limit 與封鎖不是免費的，而是基礎設施預算中持續存在的一行。
維護成本。 這份清單中的每個靜態解析器與結構規則工具，都可能因網站改版而讓 selector 壞掉。AutoScraper 自己的 README 範例，就曾在目標網站改版後需要更新價格。這就是那種 $0 授權標籤不會提到的「隱藏運算/代理成本」類別——真正消耗的是工程時間，而不是機器成本：每當目標網站的開發團隊發版改版，你就得回頭修復壞掉的擷取規則。
對於持續卡在這些問題上的團隊——selector 不斷失效、代理帳號要管理、DevOps 開銷沒完沒了——一套自架開源堆疊在把工程師工時算進去後，未必比你想像中便宜。對非開發者來說，Thunderbit 的 Chrome 擴充功能 採取的是另一種做法：把它指向你有權存取的頁面，點一下 One Click Extract，它就會自行分析頁面、找出該擷取什麼——不需要 selector，也不需要在版面變動時再維護腳本。它不是 Scrapy 在爬取框架層級的替代品，但如果你一直手動維護脆弱的 AutoScraper 規則集，這會是更合理的下一步。
決策框架：如何把工具對應到團隊限制條件
大多數比較文章只會停在「某工具最適合某情境」。那只是一個變數。實際上，團隊通常同時要平衡至少四個條件：是否需要 JS 渲染 × 團隊語言 × 所需輸出格式 × 授權限制。
| 團隊情境 | 最適合的工具 | 原因 |
|---|---|---|
| Python、靜態 HTML、快速腳本 | BeautifulSoup、AutoScraper | 不需要 JS、MIT 授權、設定最少 |
| Python、大型結構化爬取 | Scrapy | BSD-3-Clause、內建 pipeline，只有在真的需要 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 + 標註條款；需先確認法務能否接受額外條件 |
| Prompt 驅動、不固定的擷取 | ScrapeGraphAI | MIT，但要預留 LLM token 成本 |
| API 對接、自架、可接受 AGPL | Firecrawl | AGPL-3.0-or-later；在建封閉原始碼 SaaS 前先讓法務簽核 |
| 企業 Java/Hadoop 索引 | Apache Nutch | Apache-2.0，專為搜尋基礎架構而生 |
| 無程式碼、偶爾使用、非開發者 | Web Scraper 擴充功能 | 本機免費；不要把 open-core 的分層誤以為完全透明 |
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（擴充功能） | N/A（無程式碼） | open-core | ⚠️ 依方案而定 | 原生支援（即時瀏覽器） | 低 | 非開發者偶爾使用 |
結論：你該用哪一款開源網頁爬蟲？
這裡沒有單一「最佳」工具——正確答案取決於你的授權限制、團隊使用的語言，以及目標資料是在靜態 HTML 裡，還是被 JavaScript 牆包住。Scrapy 適合大型 Python 靜態爬取；Playwright 或 Crawlee 則適合無法妥協 JS 渲染的情況。若你是在餵給 LLM 流程，Crawl4AI 會很合適，只是它的授權檔有額外的標註條款，值得先快速看過。Firecrawl 的自架核心功能很強，但也帶有 AGPL 的法律議題，最好讓法務一起參與，而不是跳過。
如果 selector 維護與代理管理吃掉的工程工時，比實際爬取還多，那通常就是該考慮像 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 擴充功能提供點選式設定，不過排程與雲端功能是在付費方案後面。若你想要自動欄位偵測，又不想碰 selector，那麼像 Thunderbit 這種代理型無程式碼工具會是更實際的起點。
為什麼 Scrapy 需要額外外掛才能渲染 JavaScript？
Scrapy 是以 HTTP 為核心設計的框架——它只會送出請求並解析回來的 HTML，不會執行客戶端腳本。這種架構讓它在靜態網站爬取時既快又輕量，但也意味著 JavaScript 渲染出來的內容根本不會出現在 Scrapy 收到的回應裡。scrapy-playwright 會在無法避免渲染時，把特定請求導到真正的 Playwright 瀏覽器實例，從而補上這個缺口。
延伸閱讀
