幾乎每一篇「最佳開源爬蟲」整理文，都有一個不太起眼卻很致命的問題：沒有人讓這些工具跑同一批頁面。Scrapy 可能是在新聞文章上測，Playwright 用的是某個電商示範頁，Colly 則是作者手邊隨便抓的一個案例——接著它們就被硬排在一起，好像這些數字真的能互相比較一樣。那樣的排名，反映的是頁面差異，不是工具本身。
所以我做了那件列表通常會略過、但最理所當然的事：我先建立一組共同測試樣本，再把 9 個工具全部丟進去跑。包含靜態商品目錄、JavaScript 動態渲染的商品目錄、被導覽列和頁尾雜訊包住的文章、刻意設計的 HTTP 500 錯誤、小型站內連結爬行圖，外加兩個公開練習網站。所有工具都用同一份標準答案、同一套衡量方式、每次執行都一樣。腳本和原始輸出都放在這個公開 benchmark repo裡，你可以自己重跑。最後得到的結果，並不是那些整理文宣稱的整齊排行榜——根本不存在單一冠軍。這其實是三種不同工作，而這 9 個工具幾乎是自然而然地分成了三群。
這個測試平台怎麼做的，以及我先講清楚的一個限制
每個工具都測了相同類型的樣本：跨兩頁的 12 個靜態商品、延遲載入後由 JavaScript 注入的 8 個商品、被導覽列與頁尾樣板文字包圍但只有 3 段真正內容的文章、刻意回傳 500 的伺服器錯誤，以及一張站內連結圖。正是這樣的設計，才讓結果可以對齊——像「8/8 動態商品」這種數字，無論是 Puppeteer 還是 Crawlee 跑出來，代表的都是同一件事。
不過有個邊界，多數整理文都會跳過。每個工具的封裝都複製了這些樣本，因此絕對字元數不能直接跨工具比較——它只能作為工具內部的訊號，不是跨工具的分數。真正可比較的是召回率（當成比例看）、JavaScript 成功/失敗、以及結構表現。還有一個同樣重要的範圍註記：Crawl4AI 的靜態商品目錄測試只跑了第一頁，所以它的 6/6 代表的是較小範圍內的完整召回；其他工具則是把兩頁都爬完，達到 12/12。這不是漏抓，而是測試範圍不同。每個 fixture 的完整推理，都寫在方法說明裡。
再補一個數字前的提醒。每個封裝裡也都有一個暫定的研究分數，但我刻意沒有把它們整理成排行榜。那些分數只是用來檢查每個工具是否符合自己的證據，不是聯賽積分表——如果把它們公開成單一排名，反而會重現這整個測試想避免的「假精準」問題。這篇文章是對測試結果的整合，不是積分榜。
全部工具，一次看清楚
往下看這張表的兩欄——「支援 JS 渲染嗎？」和「內建爬行佇列」——三種工作類型其實就自己浮現了。
| 工具 | 語言 | 支援 JS 渲染嗎？ | 靜態召回 | 結構化輸出 | 內建爬行佇列 | 安裝負擔 | 授權 |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | 是（瀏覽器） | 6/6（第 1 頁） | CSS schema | 內建 BFS/DFS | 重（2 套瀏覽器堆疊） | Apache-2.0 |
| Firecrawl | 自架服務 | 是（playwright-service） | 完整 Markdown | 有 | /v1/crawl | 最重（6 個容器） | AGPL-3.0 |
| trafilatura | Python | 否 | 3/3 文章 | 否（僅文字） | 否 | 輕量 | Apache-2.0 |
| Crawlee | Node/TS | 可選引擎 | 12/12 | 透過抽取 | 有（RequestQueue） | 中等（+~80 MiB） | Apache-2.0 |
| Playwright | Node/multi | 是 | 12/12 | 手動 | 否（需手寫 BFS） | 中等（瀏覽器） | Apache-2.0 |
| Puppeteer | Node | 是（Chrome） | 12/12 | 手動 | 否（需手寫 BFS） | 中等（Chrome） | Apache-2.0 |
| Scrapy | Python | 否 | 12/12 | Feed 匯出（JSON/CSV/XML） | 有（內建） | 中等（Twisted 相依） | BSD-3 |
| Colly | Go | 否 | 12/12 | 透過 callback | 深度控制 | 輕量（1 個 binary + Go） | Apache-2.0 |
| Scrapling | Python | 否（HTTP 抓取器） | 12/12 | 有 | 否 | 中等（[fetchers]） | BSD-3 |
這張表以及後文中的中繼資料也提醒一下：星數和版本號是 2026 年 7 月初截圖下來的，這些數字變動很快。你要把它們當成當前資訊之前，最好回到各專案的 GitHub 與套件頁重新確認一次。
單工具深度評測索引
這篇整理裡的每個專案，都有對應的深度評測：
- Crawl4AI 評測
- Firecrawl 評測
- trafilatura 評測
- Playwright vs Puppeteer 比較
- Crawlee 評測
- Scrapy 評測
- Colly 評測
- Scrapling 評測
下面是它們的封面，外加兩張來自 JavaScript 測試的真實截圖，讓「8/8 動態」這件事不只是頁面上的數字。
任務一：把頁面轉成可供 LLM 使用的文字
如果你要的是可以直接餵給 RAG pipeline 的乾淨 Markdown，那就只有三個工具在競爭，而它們的設計方向完全不同。
Crawl4AI 的本質其實是瀏覽器驅動的 Markdown 產生器，包裝文案寫得再漂亮，也不必把它吹成什麼「自適應智慧、自我學習選擇器」——它根本沒有那種功能，那是另一個程式庫的把戲（等講到 Scrapling 時會再提）。但它真正做的事，做得相當好。在 Books to Scrape 練習站上，它輸出了 13,476 個字元 的 Markdown，也能用 CSS schema 做結構化抽取；而且它內建的 BFS 深度爬行器在抓取 JavaScript 頁面並截圖時，沿著爬行圖走了 5 個頁面。不過有兩個明顯缺點：它產生的原始 Markdown 會保留頁面模板文字，除非你打開內容過濾器；而那個刻意設計的 500 錯誤回傳的是 success=false——不是因為 Crawl4AI 正確捕捉到 HTTP 錯誤，而是它自己的內容判斷看見了很短的錯誤回應，直接把它標成 minimal_text ... blocked。另外，它的安裝會在磁碟上留下兩套瀏覽器堆疊。版本 0.9.0、Apache-2.0、截至 7 月初大約 7.1 萬顆星。
Firecrawl 是這一組裡最重量級的，而它的自架版確實能跑——我特別要強調「確實」，因為那套 6 容器架構（api、playwright-service、redis、rabbitmq、nuq-postgres、foundationdb）真的有成功啟動，並且從同一個 Books to Scrape 頁面產生了 9,222 個字元 的 LLM-ready Markdown。它透過內建的 playwright-service 渲染了 JavaScript 頁面，而且輸出裡真的出現了腳本後的 Einstein 引言，這證明渲染不是假的。我遇到的兩個問題，其實都不是 Firecrawl 本身的鍋；我特別講清楚，是為了避免別人照著錯誤方向修：從原始碼建置時，colima 下的 containerd snapshotter 出現一次偶發問題，所以我改用預建映像；另外，colima 的 198.18.x.x DNS 網段觸發了 Firecrawl 的 SSRF 防護，我是用 ALLOW_LOCAL_WEBHOOKS=true 解除，這只是本機開發 workaround，不應該在正式部署時關掉。自架核心也沒有 Fire-engine，也就是雲端版的 anti-block 層，而我也沒有測雲端 API。更大的警訊是授權：Firecrawl 的自架核心是 AGPL-3.0，這不是註腳，而是在商業使用前必須認真處理的法律功課。截至 7 月初，星數約 14.8 萬。
trafilatura 在這群人裡是最不跟風的那個，也是 AI 熱潮清單最容易忽略的工具。它沒有瀏覽器、沒有結構化列、只用純 Python 直接抓出乾淨的文章文字。在文章 fixture 上，它抓到了標題和 3 段中的 3 段 真正內容，並且把模板雜訊清得一乾二淨——沒有出現「Login」、「Subscribe」或「Copyright」之類的內容，作者與日期也一併回來。放到公開商品頁，它回傳了 1,324 個字元的乾淨文字。它的限制也完全符合設計：如果丟給它的是商品目錄，它會回傳 12 個商品名稱文字，但 0 筆結構化列——文字有了，結構沒有；而且它不會渲染 JavaScript。版本 2.1.0（目前版本）、Apache-2.0、約 6,200 顆星。若你只做文章抽取，它會是我第一個想到的選擇。
前面提到的兩個 Markdown 字元數——Crawl4AI 的 13,476 與 Firecrawl 的 9,222——雖然來自同一個公開頁面，但不能把它們解讀成品質高低。它們反映的是不同的 Markdown 策略（每個工具保留多少頁面外殼），不是誰輸誰贏。這正是前面說的「工具內訊號」規則，這裡完整地展現出來。
任務二：穩定渲染 JavaScript
有些資料在 JavaScript 跑完之前，根本不會出現在 HTML 裡；這時候，真正的瀏覽器就不再是可有可無的選項了。這一類任務有三個工具在做，而且其中兩個幾乎像是同一個工具。
Playwright 和 Puppeteer 在我丟給它們的每一項測試上都打平。兩者都在本機 fixture 上渲染出 8/8 動態商品，也都在公開的 Quotes JS 網站上抓到 10 筆；靜態頁面召回率也同樣是 12/12，而且都能乾淨地處理 500 錯誤（Puppeteer 會回傳 response 物件，而不是直接丟例外）。兩者都沒有自帶爬行佇列，所以要走完那張 12 頁連結圖，就得自己寫 BFS。真正的差別只有覆蓋範圍：Playwright 支援 Chromium、Firefox、WebKit，並可搭配 Python 和 .NET；Puppeteer 則是以 Chrome 為核心，且只支援 Node。這裡也說明兩個版本資訊，因為更新很快：我測的是 Playwright 1.56.0，對照當時的 1.61.1，只用 Chromium；Puppeteer 測的是 24.16.0，對照當時的 25.3.0——你要重新跑一次，或自行打折看待。兩者都是 Apache-2.0，星數大約分別是 9.2 萬和 9.5 萬。
Crawlee 解決了另外兩個工具沒處理好的佇列問題。它把 Cheerio（HTTP）引擎和 Playwright（瀏覽器）引擎包進同一套 API，單看一個頁面的差異，就能看出它的核心賣點：Cheerio 引擎看不到 0 筆 JavaScript 注入項目，Playwright 引擎本機則是 8/8 全抓到（公開網站也是 10 筆），而且兩者切換只要改一行。它還提供真正的 RequestQueue，這也是它能被歸在這一類，而不是下一類的原因。只是有個多數標題不會寫出來的代價：瀏覽器引擎需要另外執行 npx playwright install，光這部分就多出約 80 MiB，而 npm install crawlee 不會幫你抓。版本 3.17.0、TypeScript、Apache-2.0、約 2.46 萬顆星。
任務三：不靠瀏覽器也能高速爬取
如果頁面本身沒有 JavaScript，硬上瀏覽器反而是昂貴的過度設計。這裡由三個以 HTTP 為主的工具競爭，一個代表一種語言哲學，而它們的差異還挺有意思的。
Scrapy 是這組裡工程感最重的框架——spider、JSON/CSV/XML 的 feed 匯出、AutoThrottle，該有的都有。它做到了 12/12 的靜態召回、抓到文章的 3/3 段落，並且在爬行圖上以深度 0–2 走了 11 個頁面，還透過 handle_httpstatus_list 接住了 500。它的世界觀才是最有意思的地方：它不渲染頁面，而是重送請求。丟給它 JavaScript 頁面時，它抓到的是 0 個節點；但同一個頁面背後的 JSON API 送給它之後，卻能拿到 8/8。這就是 Scrapy 的哲學：找出頁面實際打出去的請求，直接重播，不必真的去操控瀏覽器。代價則是相對龐大的依賴堆疊（Twisted、lxml、parsel），而且我只在小型 fixture 上測過。版本 2.17.0、BSD-3-Clause、約 6.3 萬顆星。
Colly 是 Go 的答案，而且它對自己是什麼這件事講得非常直白：一個靜態 binary、透過 OnHTML、OnResponse、OnError 這些 callback 驅動，並且內建深度控制。它漂亮地拿下 12/12 靜態召回，透過 OnResponse 從 JSON API 抓到 8/8，也用 OnError 接住了 500，並在深度 2 的爬行中走到 17 個頁面——這裡我會特別這樣寫，因為那個頁數是測試框架自己記錄的計數，不代表 Colly 保證的完整性。它不做 JavaScript：動態 fixture 和 Quotes JS 網站都回傳 0，這本來就是設計如此。你需要 Go toolchain 才能建置它，而且目前 module 版本（v2.3.0）還領先標記發布版（v2.2.0）。Apache-2.0，約 2.5 萬顆星。
Scrapling 是這組裡的專家，而且它確實配得上這個定位。它的 adaptive selector 設計，目的是在 markup 變動後重新找回元素——所以當我把目標 HTML class 從 product-name 改成 product-title 時，普通 selector 會抓到 0，但 adaptive re-match 仍然把原本追蹤的元素找了回來。在純 HTTP 抽取上，它同樣拿到 12/12 的靜態頁面和 8/8 的 JSON API。只是它自己的文件也沒迴避的事實是：在一個模擬多元素的測試裡，它只恢復了 3 個中的 1 個——這是耐變動的元素追蹤，不是完全恢復，千萬別把它想得太神。它的基礎安裝 pip install scrapling 還需要加上 [fetchers] 才能順利啟動，而且 StealthyFetcher 應該被看作合規風險提醒，不是適合拿上台簡報的賣點。版本 0.4.10（目前版本）、BSD-3-Clause、約 6.87 萬顆星。
這三種任務背後的共通模式
把這 9 個工具排在一起，清楚的模式就浮現了。對任何以 HTTP 為主的工具來說，靜態頁面 12/12 的完整召回只是基本門檻，沒有哪個在簡單場景翻車，所以它不是區別點。只有在真的有 JavaScript 參與時，瀏覽器工具才值得那些額外重量，而它們也確實要為此付出安裝成本：瀏覽器堆疊、額外安裝，或一整組容器服務。至於「內建爬行佇列」那一欄，其實就是 framework 和 engine 的分界線——Scrapy 與 Crawlee 會幫你安排流程，而 Playwright 和 Puppeteer 則要你自己寫 BFS。這就是整個市場的結構。沒有任何一個工具能稱霸全場，因為它們根本沒在玩同一種遊戲。
那到底該怎麼選
這個測試不願意選出唯一冠軍，因為真正的答案不是工具，而是問題本身——你要做的是哪一種任務？
- 需要可直接餵給 LLM 的 Markdown？ 如果你要的是乾淨的文章文字，就選 trafilatura；如果你還想同時要 CSS 抽取與 JavaScript 渲染，選 Crawl4AI；如果你要的是自架服務，且能接受 AGPL-3.0 授權和 6 容器的重量，那就選 Firecrawl。
- 需要渲染 JavaScript？ 就選 Playwright 或 Puppeteer 來做原始渲染——以引擎與語言來挑，因為它們在這件事上基本打平；如果你還希望連爬行流程都有人幫你安排，選 Crawlee。
- 要高速爬靜態頁面或可重現的 API？ Python 全方位框架選 Scrapy，想要單一 binary、追求 Go 的原始速度就選 Colly；如果你最在意的是面對版面變動時能不能活下來，那就是 Scrapling。
只要工具和工作對上，每一個選擇都站得住腳。選錯分類——例如拿瀏覽器工具去抓純靜態頁，或拿 HTTP parser 去對付 JavaScript 網站——就算是網路上評價最高的程式庫，也一樣會讓你失望。
那麼，受管控的 AI API 又適合放在哪裡？
上面這些工具全部都是免費、開源，而且你可以自己部署。這同時也是測試結果一再浮現的共同代價：瀏覽器環境、爬行程式、反機器人攻防，以及所有維運工作，全都得你自己扛。對很多團隊來說，這種控制權正是重點；而當你真的要接手時，授權地圖就很重要了——大多數工具都很寬鬆（Crawl4AI、Crawlee、Playwright、Puppeteer、Colly 都是 Apache-2.0；Scrapy 和 Scrapling 是 BSD-3），只有 Firecrawl 的 AGPL-3.0 自架核心，在商業使用前需要仔細評估。
但也請注意，這個測試同時顯示了這些工具「做不到什麼」。渲染、爬行、結構化、繞過封鎖——很少有工具能一次全包，而且你還得自己維護。受管控的 AI 爬取 API，會把整套流程濃縮成一次請求。我們在 Thunderbit 的開發者介面就是其中一個選項；對技術團隊來說，真正有價值的是 API、MCP server 和 CLI，而不是瀏覽器擴充功能。POST /distill 會回傳乾淨 Markdown，POST /extract 會回傳依 schema 定義的 JSON，JavaScript 渲染和反機器人處理都在伺服器端完成，而不是由你的電腦負責。還有專門給 agents 與 coding assistant 用的官方 MCP server —— thunderbit_suggest_fields 可免費規劃抽取欄位，接著 thunderbit_distill（1 點 credit）和 thunderbit_extract（20 點 credits）負責執行；如果你要在終端機或排程工作裡使用，也可以透過 npx @thunderbit/thunderbit-cli 取得 CLI。對團隊裡非工程人員來說，還有免程式的 Chrome extension；而 價格頁 也同時涵蓋這兩種使用情境。
這裡的取捨，其實和整個測試平台想傳達的是同一件事：你可以自己跑、自己維護最多 9 個程式庫，單次成本是 0；或者把基礎設施交出去，按次付費。兩者都沒有錯，差別只在於你到底想擁有多少層技術堆疊。如果你想先看看實際抽取長什麼樣子，Thunderbit YouTube 頻道 有完整示範。
{{INTERNAL_BLOG_LINKS}}
結論
不存在單一最強的開源爬蟲；任何自信滿滿直接丟你一個答案的清單，其實都在悄悄迴避真正決定結果的問題：你要做的是哪一種任務？把頁面轉成文字、渲染 JavaScript、還是不用瀏覽器也能高速爬行——市場其實已經清楚分成這三類，而每一類裡的選擇，最後都取決於語言與安裝負擔，而不是什麼全能冠軍。
如果你只從這篇文章帶走一個習慣，那就記住這件事：在真正採用之前，先用你自己的頁面測一次。這裡的每個數字都可以在benchmark repo 裡重現，原因正是如此——因為在通用整理文裡排名最前的工具，和在你真實目標頁上撐得住的工具，往往不是同一個。
立即試用 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
哪個才是最好的開源網頁爬蟲？ 沒有單一最佳解，要看任務類型。如果你要 LLM-ready 的文字，trafilatura 或 Crawl4AI 很適合；如果需要 JavaScript 渲染，選 Playwright、Puppeteer 或 Crawlee；如果重點是高速 HTTP 爬行，Scrapy 或 Colly 會更合適。在共享測試平台上，每個工具都只在自己的分類裡表現突出，離開分類後差距就很明顯，所以那種一體適用的排名其實很容易誤導人。
哪些開源爬蟲可以渲染 JavaScript？ Crawl4AI、Firecrawl、Playwright、Puppeteer，以及 Crawlee 的 Playwright 引擎都能渲染 JavaScript。Scrapy、Colly、trafilatura 和 Scrapling 預設的 HTTP 抓取器都不行——它們要嘛需要頁面背後有可重播的 API（Scrapy 就是這種做法，能從 JSON endpoint 抓到 8/8），要嘛就得另外切換到瀏覽器模式。
抓網站一定要用無頭瀏覽器嗎？ 只有在資料是 JavaScript 執行後才出現的情況下才需要。如果單純的 HTTP request 加上 parser 就能抓到內容，那麼瀏覽器其實是昂貴的過度設計——這種情況下，Scrapy、Colly 或 Scrapling 會輕很多、也快很多。
這些工具哪個最適合商業使用？ 大多數都屬於寬鬆授權：Apache-2.0（Crawl4AI、Crawlee、Playwright、Puppeteer、Colly）或 BSD-3-Clause（Scrapy、Scrapling）。唯一需要特別小心的是 Firecrawl 的自架核心，它是 AGPL-3.0；如果你要拿它做商業產品，建議先仔細做授權審查。
這些 benchmark 數據可以重現嗎？ 可以。每個執行器、每個 fixture、每筆原始結果都放在公開的 MIT 授權 repo 裡。唯一要記住的是：召回率和結構結果可以跨工具比較，但絕對字元數只能當作工具內部訊號，因為每個封裝都各自複製 fixture，而不是共用同一份標準檔案——所以請比較比例與成敗，不要比較原始字元總數。
