幾乎每一篇「最佳開源爬蟲」總整理都有一個不太起眼的問題：沒有人拿相同的頁面去測試所有工具。Scrapy 可能拿新聞文章來測，Playwright 用某個電商示範頁，Colly 則是作者手邊剛好有什麼就拿什麼來跑——接著這些工具又被硬生生排成高下，好像那些數字真的能放在一起比。其實，那份排名反映的是頁面，不是工具本身。
所以我做了這件看似無聊、卻最該有人做的事：我先設計了一組統一的測試樣本，然後把九個工具全部丟進去跑。內容包含靜態商品目錄、由 JavaScript 渲染的商品目錄、藏在導覽列與頁尾雜訊中的文章、刻意製造的 HTTP 500 錯誤、小型內部連結爬取圖，以及兩個公開練習網站。相同的真值、相同的指標、每一次都一樣。腳本與原始輸出都放在這個公開的 benchmark repo 裡，你可以自己重新跑一次。最後得到的結果，並不是那些總整理常常 обещует 的整齊排行榜——因為根本沒有單一冠軍。真正的情況比較像：有三種不同工作，而這九個工具幾乎會自然而然地各自歸位。
測試是怎麼做的，以及我先說出口的唯一限制
每個工具都被放進相同的測試形狀：12 個分布在兩頁的靜態商品、8 個在延遲後由 JavaScript 注入的商品、包在導覽列／頁尾樣板中的一篇真實文章、刻意回傳 500 的伺服器錯誤、以及一張內部連結圖。正因為這樣設計，結果才能對齊——像「8/8 動態商品」這種數字，不管是 Puppeteer 還是 Crawlee 跑出來，意思都完全一樣。
但這裡有個多數總整理都會跳過的界線。每個工具的資料包都各自複製了那些測試樣本，所以絕對字元數不能在工具之間直接比較——請把它們視為「工具內」訊號，而不是跨工具比分。真正可以互相比較的，是召回率（可視為比例）、JavaScript 成功／失敗，以及結構行為。還有一個同樣重要的範圍註記：Crawl4AI 的靜態目錄測試只涵蓋第一頁，所以它的 6/6 代表的是較小範圍內的完整召回；其他工具則抓了兩頁，因此是 12/12——這是範圍較小，不是漏抓一半。更完整的推理過程，逐一對應每個測試樣本，都放在 方法說明 裡。
在看數字之前，還有一個提醒。每個資料包也都有一個暫時性的研究分數，但我刻意沒有把它們做成排行榜。那些分數只是我用來檢查各工具是否符合其自身證據的內部輔助，不是聯盟積分榜——如果把它們公開成排名，反而會重演這整個研究想避免的「看起來很精準，其實不精準」問題。這篇文章是對測試結果的整合，不是積分板。
全部工具，一次看懂
沿著這張表的兩欄看下去——「支援 JS 渲染？」和「內建爬取佇列」——三種工作型態幾乎就自己現形了。
| 工具 | 語言 | 支援 JS 渲染？ | 靜態召回率 | 結構化輸出 | 內建爬取佇列 | 安裝負擔 | 授權 |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | 是（瀏覽器） | 6/6（第一頁） | 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 與 Puppeteer 比較
- Crawlee 評測
- Scrapy 評測
- Colly 評測
- Scrapling 評測
以下是它們的封面，以及兩張來自 JavaScript 測試的真實截圖，讓「8/8 動態資料」不只是紙上的數字。
工作一：把網頁變成可供 LLM 使用的文字
如果你要的是能直接餵進 RAG pipeline 的乾淨 Markdown，那麼真正能打的只有三個工具，而且它們的設計方向完全不同。
Crawl4AI 底層其實是一個由瀏覽器驅動的 Markdown 產生器。順帶一提，搜尋結果頁面常跟它綁在一起宣傳的「adaptive intelligence self-learning selector」說法，值得先劃掉：它其實沒有這種功能——那是另一個套件的特性（等到談 Scrapling 時我會再說）。但它真正做的事，做得不錯。在 Books to Scrape 練習網站上，它輸出了 13,476 個字元 的 Markdown，並且能用 CSS schema 做結構化擷取；它內建的 BFS 深度爬取則在爬圖測試中走了 5 個頁面，同時也成功渲染了 JavaScript 頁面並截圖。不過它有兩個明顯缺點：原始 Markdown 會保留頁面樣板內容，除非你開啟內容過濾；而那個刻意製造的 500 錯誤回應結果是 success=false，原因不是它漂亮地辨識了 HTTP 錯誤，而是它自己的內容判斷把那段很短的錯誤頁內容標成了 minimal_text ... blocked。再加上安裝會把兩套瀏覽器堆疊丟進你的磁碟。版本 0.9.0、Apache-2.0，截至 2026 年 7 月初大約 7.1 萬星。
Firecrawl 是裡面最重的一個，而自架真的能跑——我說「真的」是因為那套六容器堆疊（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 解掉——這是本機開發的變通法，正式部署時不應該這樣關。它的自架核心也沒有 Fire-engine，也就是雲端版本的 anti-block 層；我也沒有測試雲端 API。更大的警訊是授權：Firecrawl 的自架核心是 AGPL-3.0，這不是註腳，而是在商業使用前一定要認真研究的法律事項。到 2026 年 7 月初，大約 14.8 萬星。
trafilatura 是這組裡最逆風的一個，也是 AI 熱潮清單最容易忽略的那種工具。沒有瀏覽器，沒有結構化列，只有用純 Python 快速、乾淨地抽取文章文字。在文章測試樣本中，它抓出了標題與 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
有些資料就是不會出現在 HTML 裡，直到 script 執行之後才冒出來；這時候，真正的瀏覽器就不是可選項了。這個工作有三個工具能做，而其中兩個幾乎可說是同一個工具。
Playwright 和 Puppeteer 在我丟給它們的每一項測試上都打平。兩者都在本地樣本上渲染出 8/8 個動態商品，在公開的 Quotes JS 網站上也都拿到 10 筆；兩者都完成了 12/12 的靜態召回，且對 500 錯誤的處理也都很乾淨（Puppeteer 會回傳 response 物件而不是直接丟錯）。兩者都沒有內建爬取佇列，因此都得手寫 BFS，而這個 BFS 在爬圖中跨深度 0–2 走到了 12 個頁面。真正的差別只在覆蓋範圍：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，星數約 92k 與 95k。
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、約 24.6k 星。
工作三：不用瀏覽器，快速爬取
如果頁面沒有 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），而且我只在小型測試樣本上驗證它。版本 2.17.0、BSD-3-Clause、約 63k 星。
Colly 是 Go 的答案，而且它對自己是什麼講得非常直接：一個靜態 binary，透過 OnHTML、OnResponse、OnError 進行 callback 驅動，再加上深度控制。它漂亮地拿下 12/12 的靜態召回，透過 OnResponse 從 JSON API 抓到 8/8，經由 OnError 接住 500，並且在深度 2 的爬取中走到了 17 個頁面——這裡我會特別這樣寫，因為那個頁面數是測試框架自己的計數，不是 Colly 承諾能保證完整覆蓋的意思。它不做 JavaScript：動態樣本與 Quotes JS 網站都回傳 0，這本來就是設計如此。你需要 Go toolchain 才能建置它，而且目前 module 版本（v2.3.0）已經比標記版（v2.2.0）超前。Apache-2.0、約 25k 星。
Scrapling 是專門型工具，而且它確實配得上這個稱呼。它的 adaptive selectors 會在 DOM 結構變動後重新定位元素——所以當我把目標元素的 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、約 68.7k 星。
這三種工作背後的共同規律
把這九個工具排在一起，你會看到一個很乾淨的結論。對所有以 HTTP 為核心的工具來說，靜態完整召回——也就是平平的 12/12——只是入場券；它們沒有誰在簡單題目上翻車，所以那不會是區別優劣的重點。瀏覽器工具只有在真的碰上 JavaScript 時，才值得它們額外的重量，而它們也都會在安裝上付出代價：要嘛是一整套瀏覽器堆疊，要嘛是額外安裝，要嘛是一個完整的容器艦隊。而「內建爬取佇列」這一欄，本質上就是框架與引擎之間的分界線——Scrapy 和 Crawlee 幫你做好編排，Playwright 和 Puppeteer 則要你自己把 BFS 寫出來。這就是整個領域的輪廓。沒有誰能拿下總冠軍，因為大家根本不是在玩同一種比賽。
那到底該選哪一個？
這份測試不肯選出單一冠軍，因為正確答案不是某個工具，而是一個問題：你在做三種工作中的哪一種？
- 需要可直接給 LLM 用的 Markdown？ 如果你要的是乾淨文章文字，選 trafilatura；如果你同時需要 CSS 擷取與 JavaScript 渲染，而且希望都包在同一個套件裡，選 Crawl4AI；如果你要的是自架服務，且能接受 AGPL-3.0 授權與六容器的重量，就選 Firecrawl。
- 需要 JavaScript 渲染？ 只看原始渲染能力，Playwright 或 Puppeteer 都可以；請依引擎與語言來選，因為其他表現幾乎打平。若你還想要爬取編排一起包好，Crawlee 會更合適。
- 要在沒有瀏覽器的情況下，大規模爬靜態頁或可重現的 API？ Scrapy 適合完整的 Python 框架；Colly 適合追求 Go 的純粹速度與單一 binary；而當你最在意的是「結構改版後還能不能活下來」，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 渲染與反爬則在伺服器端處理，而不是由你的電腦負責。也有正式的 MCP server 可供 agents 與 coding assistants 使用——先用 thunderbit_suggest_fields 免費規劃抽取欄位，再用 thunderbit_distill（1 點）與 thunderbit_extract（20 點）執行；另外還有可用 npx @thunderbit/thunderbit-cli 直接安裝的 CLI，適合終端機與 cron 工作。若你的團隊裡還有非工程人員，也可以使用免程式的 Chrome extension，而 pricing 也同時涵蓋這兩種需求。
而這裡的取捨，其實和整份測試一直在迴圈的問題一樣：你要自己免費維運最多九個函式庫，還是把基礎設施交出去、按次付費？兩種都沒有錯，只是看你到底想掌握多少層堆疊。如果你想先看實際抽取效果，可以到 Thunderbit YouTube 頻道 了解操作流程。
結論
不存在單一最佳的開源爬蟲；任何自信地丟給你一個答案的清單，都默默藏起了真正決定結果的問題：你到底在做三種工作中的哪一種？把網頁變成文字、渲染 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），要嘛就得切換到另一種瀏覽器模式。
抓網站一定要用 headless browser 嗎？ 只有在資料是 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 數字可以重現嗎？ 可以。每個 runner、fixture 與原始結果都放在公開且採 MIT 授權的 repo 裡。唯一要注意的是：召回率與結構結果可以跨工具比較，但絕對字元數只能當作工具內訊號，因為每個資料包都是各自複製測試樣本，而不是共享同一份標準副本——所以請比較比例與成功／失敗，不要比較原始字元總數。
