搜尋「Colly」，第一個形容詞幾乎永遠都是同一個：快。Go 爬蟲很快、因為可編譯所以快、因為沒有瀏覽器卡在中間所以快。只是幾乎沒有人真的拿數字來驗證它。
所以我不再只聽說法。我架了一個小型測試站，用 Colly 去跑，觀察這個函式庫到底做了什麼——在真實頁面上的擷取成功率、失敗請求如何被分流、以及限制深度的爬取能走多遠。先講結論：靜態內容擷取拿到滿分召回率，500 錯誤也準確落在該去的位置，而一個有深度限制的爬取流程，從單一靜態二進位檔出發、沒有瀏覽器掛載，最後走到了 17 個頁面。至於那些由 JavaScript 渲染的內容，函式庫回傳的是乾淨的 0——而這剛好也是「快」這個口號最常跳過的部分。
Colly 到底是什麼，又不是什麼
Colly 自稱是「適用於 Golang 的優雅爬蟲與抓取框架」，這句話比看起來更重要。它是一個 Go 函式庫——截至 2026-07-09，gocolly/colly 大約有 ~25.4k stars，採用 Apache-2.0 授權。它不是你下載後直接對著某個 URL 砸下去的命令列工具。你要寫 Go 程式、匯入套件、接上幾個回呼函式，最後把成果編譯成單一可執行檔。
它的心智模型是事件驅動，這也正是很多習慣「發請求、解析結果」的人第一次用時會卡住的地方。你不會一行行遍歷回應再把欄位拆出來，而是把處理器掛到 Collector 上，讓函式庫在抓取頁面時自動觸發。OnHTML 會在每次匹配到 CSS selector 時執行你的擷取邏輯。OnResponse 會直接把原始回應 body 交給你，這在資料是 JSON 而不是 HTML 時尤其重要。OnError 則會攔住那些失敗的請求。爬取也是同樣的運作方式：在處理連結的 handler 裡，對找到的 URL 呼叫 Visit()，Colly 會把它們排入隊列，而 MaxDepth 決定這次爬取能走多深。回呼函式、造訪隊列、深度限制、編譯後的靜態二進位檔。沒有直譯器、沒有 runtime、也沒有把 headless Chrome 默默塞進記憶體裡。
回呼模型，以及它為什麼會改變你對擷取的感受
這些回呼函式就是這個工具的靈魂，所以值得慢慢看。這次測試裡，真正承擔全部工作的只有三個。
OnHTML(selector, handler) 是你最常用的一個。把它註冊在 .product 或 article p 上，Colly 就會在解析 DOM 時，對每個匹配到的元素呼叫你的 handler。結構化擷取就是在這裡完成的，而且寫起來很順：你描述的是你要什麼，而不是把抓取流程一行行寫出來。
OnResponse(handler) 則更底層一些，會直接把原始位元組交給你。當目標回傳的是 JSON 而不是標記語言時，你甚至不需要碰 DOM——自己反序列化 body 就好。正是這個回呼，讓 Colly 在我的測試中能直接處理 JSON API，而完全不需要解析任何 HTML。
OnError(handler) 是大家最容易忘記的一個，直到某個爬蟲在凌晨三點掛掉。當請求失敗時它會被觸發，並把回應交給你，方便你讀取狀態碼並決定下一步。會靜悄悄吞掉失敗的爬蟲，比直接報錯的還糟；Colly 兩者都不是，這點比聽起來更重要，尤其當工作需要無人看管地長時間跑時。
還有兩個實務上很重要的設計。MaxDepth 會限制爬取深度，因此一個會追連結的 collector，不會無止境地在網路上亂逛，只會走到設定的層數。再來就是編譯輸出是一個單一的靜態 Go 二進位檔——編譯一次，就得到一個沒有 runtime 相依性的檔案，可以直接丟到伺服器或 CI 工作裡執行。如果你曾在一台新機器上為 Python virtualenv 折騰掉整個下午，那這種部署方式看起來絕對是優點，而不是註腳。
安裝與環境準備——沒人會特別提到的 Go 工具鏈
相依性故事很短，但有一個真正的門檻，所以我先講在前面再談安裝。我的測試機器上原本沒有 Go，而 Colly 是 Go 函式庫，所以第一步就是先把工具鏈裝上去——我透過 Homebrew 安裝了 Go 1.26.5。如果你的團隊本來就不是 Go 生態圈的一員，真正的摩擦點其實在這裡。不是函式庫本身，而是讓它能在第一行程式碼編譯之前就運作的語言環境。
Go 就位後，拉下 Colly 就非常順。go get github.com/gocolly/colly/v2 一路解到 v2.3.0，過程毫無波折——沒有瀏覽器、沒有 headless 方案，最後只有一個編譯好的二進位檔。把這點跟那些先裝解析器、再在第一次抓取時因為缺少一串額外套件而崩掉的 Python 爬蟲相比，這個流程舒服得很。這裡的「平淡」其實是褒義。
有個精確但很重要的提醒，這點若你真的去挖版本資訊，肯定會搞混。Go proxy 上最新的 module 是 v2.3.0，發佈於 2025 年 12 月；而 GitHub Releases 裡最新的 tag 仍是 v2.2.0，時間是 2025 年 3 月。所以我實測的 v2.3.0，其實比 repository 的 Releases 頁面顯示的還新。這只是 Go modules 與 GitHub tags 隨時間逐漸脫節的結果，不代表哪裡壞掉了。只是別被 go get 和 Releases 頁面給出不同數字這件事嚇到。
實測——「快」背後的數字
我把 Colly 跑在一個基於 Go httptest 的自包含 fixture server 上，再加上兩個公開 demo 網站，所以結果是可重現的，不是我單方面講故事。以下是實際回傳的內容。
| 測試 | 目標 | 結果 |
|---|---|---|
| 靜態目錄 + 分頁 | 本地 fixture | 12/12 商品，召回率 1.0 |
| 文章擷取 | 本地 fixture | 標題 + 3/3 段落 |
| 動態 JSON API | 本地 fixture | 透過 OnResponse 擷取 8/8 項目，召回率 1.0 |
| HTTP 500 處理 | 本地 fixture | 轉由 OnError 處理，狀態碼 500 |
爬取圖譜（MaxDepth 2） | 本地 fixture | 17 個頁面 |
| Books to Scrape | 公開 demo | 20 個商品 |
| 動態頁面（無 JS） | 本地 fixture | 0 個卡片（符合預期） |
| Quotes JS（未渲染） | 公開 demo | 0（符合預期） |
從上到下看，整體輪廓很一致。靜態擷取非常乾淨——目錄頁 12 個商品全抓到，文章的三個段落也都拿到，而且全部由 OnHTML selector 驅動。JSON API 測試根本沒有啟動 HTML parser：OnResponse 直接把 body 交出來，我自己反序列化後，8 個項目全數回來。500 測試是我最在意的一個，因為它區分了一個你能放心讓它跑整晚的爬蟲，和一個不行的爬蟲——Colly 把失敗送進 OnError，也把狀態清楚露出來，沒有當機，也沒有默默吃掉錯誤。至於公開的 Books to Scrape demo，它也在沒有特別處理的情況下抓到 20 個商品。
爬取結果才是重點，我要把話說精準一點。使用 MaxDepth(2) 的 collector，在追連結並把它們解析成絕對 URL 後，於我的 fixture 圖譜中走到了 17 個頁面。這才是把「快的 Go 爬蟲」真正落到頁面數字上的方式，而不是停留在感覺上。不過請注意說法——是「在 depth-2 的爬取中走到 17 個頁面」，不是在宣稱 Colly 內部有什麼絕對契約保證「深度一定是 2，不會再多一層」。能被驗證的、誠實的說法只有這個：在深度上限設為 2 的情況下，這次爬取穿過圖譜並抵達了 17 個頁面。
接下來是上限，也就是那些「它真的超快」的文章通常開始安靜下來的地方。Colly 不會執行 JavaScript。我把它對準一個 JavaScript 渲染的 fixture，結果拿回 0 個卡片；再把它對準公開的 Quotes to Scrape JS page，也一樣是 0。這不是 bug，也不是批評。Colly 是一個 HTTP crawler——它下載並解析 HTML，但不會啟動瀏覽器去執行 client-side script。和 Scrapy 及其他 HTTP-first 爬蟲一樣，只要你要的內容必須等 JavaScript 執行完才會出現，那 Colly 每次都只會給你空結果，單靠速度也改變不了這件事。若要用它處理這類頁面，你得搭配 renderer，或直接選一個內建瀏覽器渲染的工具。
我也要坦白講清楚，有哪些東西我這次沒有測，免得有人把結果延伸過頭。我沒有測 async collector、rate-limiting 與 polite config、proxy 旋轉，也沒有測 queue 和 storage backend。這些功能 Colly 都有。我測的是擷取與爬取的核心，而不是大規模擴充的基礎設施。README 裡宣稱單核心吞吐量可超過每秒一千個請求，那是專案自己的數字；我量的是頁面數與召回率，不是吞吐量。所以我說「快」，指的是我實際量到的編譯式 Go 擷取路徑，不是在跟 Scrapy 做我沒跑過的正面吞吐比較。
優缺點
優點：
- 靜態擷取的召回率完整——
OnHTML成功抓到 12/12 目錄商品與 3/3 文章段落。 - 透過
OnResponse可乾淨處理 JSON，不必解析 DOM——8/8 API 項目全部到手。 - 錯誤分流正確——500 狀態落入
OnError，狀態清楚顯示，沒有當機。 - 單一 collector 的深度限制爬取可走到 17 個頁面。
- 單一靜態 Go 二進位檔、零 runtime 相依性——部署與維運體驗極佳。
- Apache-2.0 授權，使用上相當寬鬆。
缺點：
- 不執行 JavaScript——客戶端渲染內容一律回傳 0，沒有例外。
- 需要 Go 工具鏈；如果團隊本來不在 Go 生態裡，安裝與環境設定就是先付出的成本。
- 最新 module（
v2.3.0）比最新 GitHub tagged release（v2.2.0）還新，讀 Releases 頁面的人很容易混淆。 - 輸出資料格式要自己寫——Colly 給你的是回呼，不像 Scrapy 那樣內建資料集或 feed 匯出器。
- async、rate-limiting、proxy 與 queue backend 雖然存在，但這次都沒測；這裡的「快」是我量到的擷取路徑，不是正面吞吐數字。
Colly 適合誰，不適合誰
如果你本來就寫 Go，而且你的爬取目標是 HTML 或 JSON 為主的網站，那 Colly 非常適合。若你對「乾淨部署」的定義，是把一個二進位檔複製到機器上直接跑——不要 interpreter、不要 virtualenv、不要跟一堆依賴抽籤——那這個工具就是為這種場景而生。當擷取需求不再只是簡單抓幾個欄位時，回呼模型的價值就會很明顯：OnHTML 做結構擷取，OnResponse 處理原始 payload，OnError 則幫你看見原本容易漏掉的失敗。對於靜態頁面或 API 型目標，如果你會定時從 CI 跑它，它是個很穩、很少戲劇性的選擇。
如果你的目標很依賴 JavaScript，就該跳過它，至少也要再加一個工具。因為在我放到它前面的每一個 client-rendered page 上，Colly 回來的都是 0，而且這是設計如此，不是你可以調整的設定。若你的團隊本來就不用 Go，也不想為了抓幾個網站就額外把工具鏈架起來，那也該跳過它——語言上的承諾是真實存在的，而且需要你自己維護。如果你想要的是結構化資料直接送到你手上，而不是由你自己寫程式去解析，那 Colly 的回呼模型會把工作壓在你這邊。
替代方案——託管式 AI 爬取 API 什麼時候比較適合
Colly 是一個免費、開源、可自行編譯與執行的函式庫。你自己掌握 Go 程式、回呼、爬取邏輯，以及執行它的機器——作為回報，你不必為每次請求付費，而且整個流程都留在內部。對 Go 團隊來說，這是很合理的答案，而單一二進位部署也真的很舒服。
它停止發揮的地方，正好也是最值得拿來跟別的方案比較的地方。第一，JavaScript——Colly 不會渲染，因此任何 client-side 內容都不在它的能力範圍內，除非你額外接瀏覽器。第二，結構化輸出——Colly 提供的是回呼，而清理資料輸出的工作仍要你自己寫。託管式 AI 爬取 API 對這兩件事的處理方式不同。Thunderbit 的開發者堆疊能處理 JS 渲染，並在伺服器端回傳結構化資料。POST /distill 可以把頁面轉成乾淨、適合 LLM 的 Markdown，動態內容與 anti-bot 也會一起處理。POST /extract 則能依你定義的 JSON Schema 回傳結構化 JSON，必要時還可透過 renderMode 拉到完整瀏覽器渲染。Thunderbit 還有給 AI agent 與 coding assistant 用的 MCP server——thunderbit_suggest_fields 是免費的，所以你可以先探測頁面能吐出哪些欄位，再決定要不要真的下手——另外也提供 CLI，可用 npx @thunderbit/thunderbit-cli 在終端機、CI 和 cron 中執行。
這裡的取捨不是誰比較好，而是工作到底放在哪裡。用 Colly，你把渲染（沒有）、解析與維護都留在自己的編譯式二進位檔裡，每次呼叫不用付費，但當網站結構變動時，你得自己照顧它。用託管 API，JS 渲染、anti-bot 與結構化輸出都交出去，代價是每次呼叫都要付費。小型、Go 原生、以 HTML 或 JSON 為主，而且你願意自己持有與維護的目標？Colly 的控制力與速度會直接勝出。JavaScript 很重的頁面，或者你只是想收到 schema 化的 JSON，而不是再多寫一個回呼？那就是託管方案的舞台。如果你想看更完整的版圖，可以參考 最佳網頁爬取工具 與 最佳網頁爬取 GitHub 專案 的整理，了解像 Colly 這樣的函式庫如何與瀏覽器型和託管型方案並列。
結論
那麼，Colly 值不值得用？值得——如果你寫 Go，而且目標是高速爬取 HTML 或 JSON，它確實做到了「fast crawler」這個名聲所承諾的事，現在也有數字作為支撐。靜態擷取召回率完整。JSON 透過 OnResponse 乾淨處理。500 正確分流到 OnError，不會憑空消失。深度為 2 的爬取走到了 17 個頁面。所有這些都被編譯成單一靜態二進位檔，而且沒有 runtime 相依性——這大概是這整個類別裡最友善的部署故事了。
但還是要誠實看待它的能力邊界。它不會渲染 JavaScript——我這次測試中所有 client-side 頁面都回傳 0，而且這是永久性的，不是你漏設了某個選項。它需要 Go 工具鏈，所以非 Go 團隊一開始就得付出設定成本。你安裝的 module（v2.3.0）又比最新 tagged release（v2.2.0）還新，所以當頁面顯示不一致時別慌。還有，這裡的「快」是我測到的擷取路徑，不是我沒跑過的吞吐 benchmark。只要你把這些界線看清楚，Colly 就是一個快速、可靠、真正能部署的 Go 爬蟲——而且一旦你不再要求它執行 JavaScript，它就完全配得上這個名聲。
試試 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
Colly 真的很快嗎？有數字可以證明嗎？ 就我量測的核心路徑而言，它確實很快：編譯式 Go、靜態擷取達到完整召回（12/12 目錄商品）、JSON 處理乾淨，以及深度 2 的爬取走到 17 個頁面——而且全部來自單一靜態二進位檔。不過我沒有拿它去和 Scrapy 做吞吐量 benchmark，所以這裡的「快」應該理解為我實測到的擷取行為，而不是一個一對一速度排名。
Colly 能抓 JavaScript 渲染的頁面嗎？ 不能。Colly 是 HTTP crawler——它會下載並解析 HTML，但不會執行瀏覽器。JavaScript 渲染的 fixture 回傳 0 個卡片，公開的 Quotes JS 頁面也一樣是 0。如果你要處理 client-side 內容，就得把 Colly 接上 renderer，或改用內建瀏覽器渲染的工具。
使用 Colly 需要懂 Go 嗎？
需要。Colly 是 Go 函式庫，不是獨立 CLI——你要匯入它、註冊回呼（OnHTML、OnResponse、OnError），然後自行編譯。我測試的機器上原本沒有 Go，所以整個流程是先安裝工具鏈（1.26.5）。如果你們團隊本來就不是在 Go 環境工作，這個語言環境本身就是主要成本。
為什麼我安裝的版本，和 Colly 的 GitHub 最新 release 對不上？
因為 Go module 和 GitHub release tag 已經分岔了。Go proxy 上最新的 module 是 v2.3.0（2025 年 12 月），而 GitHub 上最新的 tagged release 是 v2.2.0（2025 年 3 月）。我測試的是 v2.3.0。這是 modules 與 tags 不同步的現象，不是安裝壞掉了。
Colly 可以免費用在商業用途嗎？ 可以，它採用 Apache-2.0 授權，使用上很寬鬆，也很適合商業情境。不過和往常一樣，正式採用前還是建議先到 repo 確認目前的授權狀態。
