開源爬蟲專案選型：先分清四類分工，再比較四個面向

在 GitHub 上搜尋爬蟲，可以找到成百上千個 repository。很多人挑專案的方法是看 star 數，直接選最熱門的來用。

熱門程度和適不適合自己的情境是兩回事。專案再熱門，如果定位和實際需求對不上，使用起來只會更費力。比較省事的入口，是先把分工釐清：一個能長期穩定運作的採集系統，本來就是由幾個職責不同的元件組成。先搞清楚每一塊在做什麼，再比較具體實作，會簡單很多。

通用爬蟲框架：適合結構穩定的頁面

這類框架負責請求排程、併發抓取和資料管線，輸入是一批 URL，輸出則是結構化結果。成熟的生態系和 middleware 機制可以插入自己的邏輯，也比較能支撐大規模、長時間執行的任務。

它無法單獨處理需要 JavaScript 渲染後才出現內容的頁面。這種情況下，初始回應往往只是一個空殼，還得再接一個渲染引擎。它比較適合列表頁、詳情頁、開放 API 這類結構穩定的目標。

瀏覽器自動化框架：需要渲染與互動的頁面

需要真實渲染、需要登入狀態，或必須點幾下才顯示內容的頁面，只能交給瀏覽器自動化。這類工具能跨不同瀏覽器核心執行，等待機制也較成熟，頁面中的 request 和 response 通常也能直接接管。

代價是資源消耗遠高於純 HTTP 請求。併發上限基本上由本機記憶體和 CPU 決定。另外，自動化本身會留下可辨識的特徵，偵測較嚴格的網站可能會識別出來。

排程與佇列元件：任務多了才需要

目標少的時候，一個 loop 可能就夠。當任務多到上千，還要控制頻率與重試時，就需要獨立的排程層：任務怎麼排隊、要開多少併發、失敗後隔多久再試、哪些任務應該放棄。把這些邏輯全塞進爬蟲框架裡，程式很快就會變得難維護。

自己組這一層最常見的問題，是只用 process 內的 queue 勉強處理。process 一重啟，排隊中的任務就全部消失。佇列至少要能持久化，也要能查詢狀態。

解析與儲存元件：決定資料能不能直接使用

抓回來的是 HTML，真正要用的是欄位。解析層要負責抽取規則管理、欄位驗證、去重與寫入儲存。對於結構常常改版的網站，可以看看是否有自適應抽取方案，改用頁面特徵而不是寫死的 selector 來定位資料，能減少不少維護成本。

儲存端還要注意冪等性。任務重試很常見，寫入時應依唯一識別值去重，否則重複資料會一路影響到後續分析。

元件組合後常見的問題

每一塊分開看都不算難，問題通常出現在銜接處。

• 排程層重試了，但解析層沒有去重，資料中出現重複列
• 瀏覽器層沒有併發上限，本機資源被吃滿，整批任務一起失敗
• 解析規則寫死在程式碼裡，網站一改版就必須重新發佈
• 各元件對同一個任務使用不同識別值，狀態對不起來，也無法從中斷點繼續

四個評估面向

把需要的類別確定之後，可以用這四項來篩選具體專案。

維護活躍度要看最近幾個月的 commit 頻率和 issue 回應速度，而不是總 star 數。停止維護的專案，在目標網站改版後可能直接失效。

文件與範例會決定上手成本。文件寫得含糊，或只有最簡單的案例，實際學習時間常常會超出預期。

擴充方式要看它留下哪些介面：能不能換 proxy、能不能接自己的渲染引擎、能不能替換儲存。保留清楚擴充點的專案，後續改造通常不用直接修改原始碼。

授權與合規風險也很容易被忽略。商用之前要確認授權類型，避開與使用方式不相容的限制性授權；採集範圍、請求頻率和目標網站條款也要一起評估，這些問題和框架本身技術上好不好是兩回事。

環境層是另一個層次的問題

框架解決的是怎麼抓資料，不會處理身分與規模問題。任務需要登入、需要依地區分開，或需要多個帳號並行時，如果全部跑在同一個瀏覽器環境裡，會出現兩個問題：不同 session 之間互相污染，Cookie 和 local storage 彼此覆蓋；目標網站也可能把原本無關的任務看成同一批存取。

成熟的做法是把瀏覽器環境做成獨立的資源層，任務從環境池申請，用完後釋放。PurpleMark 在這種架構裡就是這一層，提供可批次建立、可綁定獨立網路出口、可查詢狀態的環境資源。

合規上要劃清的界線

遵守目標網站的 robots 規則和服務條款，不採集個人資訊，不繞過技術保護措施，並控制請求頻率，不影響對方服務的正常運作。選型解決的是效率問題，這些判斷則是在決定事情本身能不能做。