網路上每一篇「Scrapy vs. Selenium」指南都在講差不多的事：Scrapy 比較快，Selenium 可以處理 JavaScript，自己選一個就好。方向大致沒錯，但「每分鐘能抓幾頁」這種萬用說法其實站不住腳。實際吞吐量會受到目標網站、網路狀況、並發數、瀏覽器生命週期、等待機制，以及反爬限制等因素影響。
這篇指南會比較真正能在不同專案中沿用的架構與營運取捨，也會補上很多比較文常漏掉的重點：瀏覽器自動化如何改變資源模型、為什麼選擇性渲染常常比全站用瀏覽器抓取更有效，以及什麼時候受管控的資料擷取 API 會比這兩個框架都更適合。
2026 年 Scrapy 與 Selenium 的快速結論
先講結論：只要是伺服器端直接渲染的頁面，Scrapy 在速度、規模與資源效率上都更有優勢。當你需要的是一個真正的瀏覽器去做真正的瀏覽器操作——點擊、輸入、等待彈窗動畫出現——Selenium 才是合適選擇。不過，這兩者對現代反爬機制都不是開箱即用就能輕鬆應對，而 Playwright 其實早就默默吃掉了 Selenium 原本承接的大多數場景。
這是我實際會用的決策表：
| 你的情境 | 建議選擇 |
|---|---|
| 靜態或伺服器端渲染頁面、量很大 | Scrapy |
| 重度 JS 的 SPA，含登入、點擊、多步驟流程 | Selenium 或 Playwright |
| 混合型網站——大多靜態，只有少數區塊需要 JS | Scrapy + Playwright 混合架構 |
| 已知 URL，只需要結構化資料，且希望維護成本最低 | AI 擷取 API（如 Thunderbit 等） |
截至 2026 年中，Scrapy 2.17.0 已可使用，Selenium 4 也持續擴展對 WebDriver BiDi 的支援，而 scrapy-playwright 則提供了一種受維護、可把特定 Scrapy 請求導向瀏覽器的做法。把上面那張決策表先記著，後面會一步步解釋為什麼它成立。
Scrapy 與 Selenium 是什麼？為什麼開發者還在爭論它們
把 Scrapy 跟 Selenium 拿來比較，有點像拿貨車和轎車相比。兩者都能把東西從 A 點送到 B 點，但一個是為了高效率搬大量貨物而設計，另一個則是為了讓人親自駕駛、並且能隨時與路面互動而打造。這場爭論之所以一直存在，是因為兩個工具都「能抓資料」，只是它們原本就是為不同任務設計的，而不少團隊往往在還沒意識到之前就選錯了工具。
Scrapy：非同步爬取引擎
Scrapy 是一個純 Python 框架，建立在 Twisted 的事件驅動、非阻塞 I/O 模型之上。它不是瀏覽器——從來都不是——它做的事情就是送出 HTTP 請求，然後解析返回的 HTML。核心原理就是這樣。因為它不需要等待瀏覽器渲染畫面，所以可以一次發出大量請求，而且不會被阻塞。
Scrapy 開箱就內建 spiders、item pipelines、feed exporters、重試中介層與速率限制。這不是那種「你得自己從零拼起來」的框架，很多生產環境最常見的問題都已經替你處理好了。Scrapy 的 架構文件 把 Engine、Scheduler、Downloader 與 Item Pipeline 拆成獨立且可替換的元件，這也是它能長壽的原因：你可以在不重寫核心的情況下擴充功能。
但缺點也很明確：沒有瀏覽器，就沒有 JavaScript 執行。如果你的資料是在頁面載入後才透過前端 fetch 呼叫取得，Scrapy 就看不到。它只會讀初始 HTML 回應，就是這麼簡單。
Selenium：可程式化的瀏覽器
Selenium 是透過 W3C WebDriver protocol 來控制真正的瀏覽器——像 Chrome、Firefox、Edge。這份標準規格讓 Selenium 不受語言與瀏覽器綁定，不是什麼只支援 Chrome 的權宜之計。它能渲染 JavaScript、執行 AJAX 請求，也能像真人一樣點擊、捲動、輸入。
這讓 Selenium 很適合所有需要互動的情境：多步驟登入、導引流程、無限捲動、會觸發 API 呼叫的下拉選單。但每個瀏覽器工作階段都很吃資源。Selenium 自己的 Grid 容量規劃建議 甚至建議，光是做規劃時就要先抓每個瀏覽器 session 約 1 GB RAM 的預算——這還沒算上實際渲染頁面時的 CPU 負載。
還有一個常讓人踩雷的細節：頁面載入完成不代表 UI 已經準備好。Selenium 文件本身也警告不要混用 implicit 與 explicit waits，因為這樣很快就會讓 timeout 行為變得難以預測。如果你的 Selenium 腳本常常不穩，通常就是這個原因。
Scrapy vs. Selenium：別拿假萬用數字談效能
可信的效能測試，必須公開目標頁面、快取狀態、網路條件、並發策略、瀏覽器重用方式、等待條件與完整程式碼。沒有這些背景，所謂的每分鐘幾頁根本只是行銷，不是證據。不過，架構層面的比較依然很有價值：
| 工作負載特性 | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| 伺服器端渲染 HTML | 直接走 HTTP 路徑 | 走完整瀏覽器路徑 | 使用 Scrapy 的直接路徑 |
| JavaScript 渲染內容 | 需要額外渲染器 | 原生瀏覽器執行 | 選擇性瀏覽器渲染 |
| 並發模式 | 非同步請求排程器 | 由你的程式或 Grid 管理瀏覽器 session | Scrapy 排程器加上瀏覽器 context |
| 資源特性 | 沒有瀏覽器渲染成本 | 有瀏覽器 CPU 與記憶體成本 | 只有標記請求才需要瀏覽器成本 |
| 最適合的衡量方式 | 在安全錯誤率下，每分鐘產出多少筆資料 | 在安全錯誤率下，每分鐘完成多少流程 | 分別衡量靜態與渲染請求的吞吐量 |
Scrapy 預設的並發請求設定只是上限，不是保證的吞吐量。真正速度取決於延遲、單網域限制、節流、重試、回應大小、解析工作量，以及目標站可接受的請求速率。Selenium 可以重用瀏覽器 session，所以它並不是每抓一頁就一定要新開一個瀏覽器；但每個啟用中的 session 仍然要執行並渲染瀏覽器環境。
混合架構之所以吸引人，是因為它能讓一般請求走 Scrapy 的 HTTP 路徑，只把需要渲染的頁面送進瀏覽器。這通常能減少瀏覽器工作量，但不代表一定更快：你仍然要分開衡量靜態與渲染路徑，把失敗率與重試率都算進去，並同時根據目標站安全性與可用記憶體來調整並發數。
影響決策的核心差異
速度不是唯一變數。真正進到生產環境後，還有幾個非常實際的因素同樣重要。
JavaScript 渲染與動態內容
單靠 Scrapy 看不到任何前端渲染內容。Selenium 因為是真瀏覽器，所以看得到全部內容。中間派方案——較早期的 Scrapy-Splash（Lua 可腳本化）與較新的 scrapy-playwright（現代且較推薦）——可以讓你在 Scrapy 的爬取迴圈中選擇性渲染 JS，而不是每個請求都交給完整瀏覽器。如果你的目標站有 80%～90% 都是靜態 HTML，只有少數頁面才需要 JS，那選擇性渲染就是很明顯的正解。因為「只部分頁面需要 JS」就把全部流量都送進瀏覽器，純粹是在浪費算力。
擴展性與並發
把 Scrapy 從 1,000 頁擴到 1,000,000 頁，大多只是資源配置問題——增加並發請求，必要時透過 Redis 分散到多個 worker。擴 Selenium 則意味著你要線性增加瀏覽器實例，也就等於線性增加 RAM 與 CPU，最後你管理的其實是一個瀏覽器農場，還得用 Selenium Grid 來處理當機復原。不是 Selenium 不能擴展，而是它的擴展本身就是一個基礎設施專案，不是改個設定就好。
資料流程與匯出
Scrapy 的 item pipeline 天生就能做驗證、去重，並匯出成 JSON、CSV 或資料庫。Selenium 則完全沒有這些，你得從頭自己寫序列化與儲存邏輯。如果你在意資料品質與後續系統整合——這本來就該在意——那 Scrapy 已經幫你先做好一大段工作了。
維護性與長期穩定度
我觀察到的一個模式是：Scrapy spider 通常比較能撐得久，因為基於 middleware 的架構本來就會強迫一些結構。Selenium 腳本則更容易脆弱——瀏覽器更新可能讓 driver 壞掉，時序問題會導致執行不穩，每次 DOM 改動都得重調 selector。我還真的看過論壇上的開發者直接說，Selenium-based scraper「感覺不是拿來做要賣給客戶的東西的最佳選擇」。老實說，如果這個專案要撐好幾個月都不大改，這個直覺通常是對的。
反爬現實檢查：2026 年各工具面對防護機制的表現
這部分是其他比較文最常輕描淡寫、但也是最能決定你的爬蟲到底能不能跑起來的一段。Scrapy 和 Selenium 都不是為現代反爬基礎設施而生的，假裝這不是問題，只會讓你在生產環境裡被突襲。
| 防護層 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS 渲染 | ❌ 需要中介層 | ✅ | ✅ | ✅ 內建 |
| TLS 指紋 | ⚠️ 可被偵測 | ⚠️ 可被偵測 | ⚠️ 較好，但未完全解決 | ✅ 已處理 |
| CAPTCHA 解題 | ❌ 手動處理 | ❌ 手動處理 | ❌ 手動處理 | ✅ 內建 |
| 速率限制輪替 | ⚠️ 自行處理代理 | ⚠️ 自行處理代理 | ⚠️ 自行處理代理 | ✅ 受管理 |
Scrapy 會直接在瀏覽器指紋檢查中失手，因為它根本不是瀏覽器——它只是個 HTTP 客戶端。很多反爬服務商會直接把不像真瀏覽器的流量標記出來。Selenium 因為確實是一個真瀏覽器，所以能通過基本的 JS 檢查，但它還是會暴露像 navigator.webdriver 這類訊號；這是個標準化旗標，在自動化情境下會是 true。像 undetected-chromedriver 這類補丁會試圖掩蓋這些特徵，但它們本質上就是在和持續更新偵測規則的反爬供應商玩打地鼠。
隱身攻防戰：為什麼自建方案很脆弱
關於反偵測補丁，最不舒服但也最真實的一點是：它們更像維護跑步機，不是一次性的解法。undetected-chromedriver 和 playwright-stealth 會一直有效，直到 Cloudflare Turnstile 或 DataDome 發布更新，把你原本用的技巧偵測出來。然後你又得重新修補。我看過一些團隊花在維持隱身層的工程時間，比真正寫爬蟲本體還多。
速率限制也值得單獨提一下。當伺服器回傳 429 Too Many Requests 時，Retry-After 標頭只是建議，不是命令——很多網站根本不會送這個標頭，有些則會透過其他訊號來限流。Scrapy 的 AutoThrottle 可以根據觀察到的延遲自動調整等待時間，但它是反應式的，不是預防式的。
這也是為什麼受管控的資料擷取 API 很值得考慮——反爬處理變成別人的工程問題，而不是你自己的。這點後面還會再提。
Playwright 因素：為什麼「Scrapy vs. Selenium」已經不是完整圖景
如果還只把它看成兩個工具的對決，其實就忽略了過去幾年爬蟲圈真正發生的變化。開發者論壇上有很多人會說類似「我從 Selenium 換成 Playwright，結果很滿意」——但大多數比較文章卻只輕描淡寫提一下，甚至根本不提。
由 Microsoft 打造的 Playwright，透過單一 API 就能控制 Chromium、Firefox 和 WebKit。它的 actionability model 會先等元素真的可見、穩定、而且可互動，才執行動作——這大幅降低了許多 Selenium 腳本常見的時序不穩問題。它也能更有效率地處理 browser contexts，讓你開出彼此隔離的 session，而不用每次都重新啟動完整瀏覽器。
什麼時候 Playwright 會完全取代 Selenium
如果是純爬蟲用途——不是要延續既有 Selenium 測試基礎設施——那在 2026 年，Playwright 通常就是更好的工具。它建立 context 更快、每頁資源占用更低、原生支援 async，而且內建網路攔截。若你是從零開始一個爬蟲專案，且沒有既有 Selenium 測試套件要保留，其實沒什麼理由先選 Selenium。
例外情況是：如果你的團隊已經有 Selenium 測試基礎設施，或者你需要某些 Playwright 沒有那麼好支援的特殊瀏覽器設定，Selenium 仍然有存在價值。
scrapy-playwright 的運作方式
scrapy-playwright 是 Scrapy 的下載處理器，只會把標記了 meta={"playwright": True} 的請求導向真瀏覽器——其他請求都留在 Scrapy 快速的非同步 HTTP 路徑上。下面是一個簡化版 spider，會抓取一個分頁型目錄，而商品卡片是透過前端 JS 渲染出來的：
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
只有真正需要渲染的頁面才會進瀏覽器。這就是混合架構的核心——不是每個請求都要付瀏覽器成本，而是只有那些真的需要的請求才付。
Scrapy-Splash vs. Scrapy-Playwright：該用哪個中介層
Scrapy-Splash 需要另外架設一個 Splash Docker 服務，還得寫 Lua 腳本來做互動——能用，但相對更重，也比較老舊。scrapy-playwright 則是直接整合進 Scrapy 的非同步 event loop，支援三大瀏覽器引擎，複雜互動也不需要再額外綁一種腳本語言。如果你 2026 年要開新專案，老實說已經沒有什麼理由再選 Splash 了。
可上線的混合架構
很多文章都只說「你可以把 Scrapy 和 Selenium 結合起來」，然後就沒了。那不是架構，那只是建議。下面才是一個真正能上生產環境的設計。
流程是這樣：Scrapy scheduler 先把請求送進 URL router，判斷頁面是靜態還是動態。靜態請求直接走 Scrapy 的標準 downloader。動態請求則會被標記並路由到 Playwright middleware，由它管理一組 browser context。最後兩條路徑都會回到同一個 item pipeline 做驗證、去重與匯出——不管資料是來自原始 HTML 還是渲染後的 DOM，最後都會變成同一份 JSON、CSV 或資料庫輸出。
如果你真的要上 production，還有幾個部署建議：用 Docker 容器化，確保 Playwright 的瀏覽器 binary 在不同環境中一致；根據可用 RAM 限制 Playwright context 的並發數（我不建議在一般 4 GB 機器上超過 8～10 個 context）；排程工作最好透過 cron 或 CI/CD pipeline 執行，不要讓一個 process 永遠掛著跑。
這種做法的好處是控制力最大，但你也要自己負責瀏覽器 binary 更新、context 生命週期 bug（沒關閉的頁面會讓爬取卡住）、proxy 輪替，以及所有需要補上的反爬方案。這是很真實的工程投入，在承諾之前最好先誠實評估。
對於想要結構化輸出、但不想自己養這些基礎設施的團隊，Thunderbit 的 CLI 採取的是另一種解法：
thunderbit batch extract --schema schema.json --file urls.txt
同樣輸出結構化 JSON。不需要 spider 程式碼、不需要瀏覽器池、不需要維護反爬連線。你用部分客製化能力換取更快上線——這不是絕對升級，而是一種合理取捨，完全取決於你的專案到底需要多少控制權。
直接跳過框架：什麼時候 AI 擷取 API 會比兩者都更好
有時候，開發者會突然發現自己其實根本不需要爬取框架。他們只是要從 500 個已知 URL 拿到結構化資料，而如果為了這件事去做 spider、瀏覽器池和反爬層，感覺太大材小用——因為通常真的就是這樣。
Thunderbit 就是要補這個缺口的。先講清楚：它不是複雜、遞迴、含自訂邏輯爬取任務中 Scrapy 的替代品。它是為了不同、且更窄的問題而設計的不同工具。
Open API：POST /extract 會接收 JSON Schema，回傳與其對應的結構化資料——不是原始 HTML，也不是一堆還要你自己解析的 Markdown。POST /distill 則做相反的事，回傳乾淨的 Markdown，可直接餵給 RAG pipeline 或 LLM。這個受管服務也支援 JavaScript 渲染與反爬處理，所以你不用自己維護那套基礎設施。現行的 Distill vs. Extract 指南 顯示 Distill 每頁 1 點、Extract 每頁 20 點；不過實際規格可能會變，正式規劃前還是先看最新文件。
MCP Server：對 Claude 或 Cursor 這類 AI agent 而言，Thunderbit 的 MCP server 把 distillation、結構化擷取、欄位建議與批次作業都變成可呼叫工具，讓 agent 可以在任務進行中直接抓取最新網頁資料，不必跳出原本環境。
CLI：官方文件中的 Thunderbit CLI 支援像 thunderbit extract <url> --schema schema.json 這類指令，很適合終端機流程與排程作業。你也可以把 distill 出來的 Markdown pipe 到其他工具，快速完成一次性研究任務。
如果你連程式碼都不想碰，Thunderbit Chrome Extension 提供的是點選式介面，對團隊裡有非工程背景、但仍需要資料的人來說尤其值得一看。如果你想看更完整的脈絡，我另外也寫了關於 AI 網頁爬取 和 免程式網頁爬取 的文章。
先誠實判斷自己屬於哪一類：如果你要做的是跨多站、含遞迴連結追蹤與自訂邏輯的複雜爬取，Scrapy 仍然是最適合的選擇。互動流程很多的任務，選 Selenium 或 Playwright。可是「我只需要這些已知 URL 的結構化資料」其實比前兩者的設計範圍都更窄，這種情境下，API 確實可以省掉 spider 程式碼、反爬接線，以及你自己維護整套基礎設施的後續成本。
Scrapy vs. Selenium vs. Playwright vs. AI API：並列比較
| 功能 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| 語言支援 | 僅 Python | Python、Java、C#、JS、Ruby | Python | REST（任何語言） |
| JS 渲染 | 否（需要中介層） | 是 | 是 | 是，內建 |
| 非同步／並發 | 原生支援，效能高 | 每個 instance 有限制 | 透過 Scrapy 原生支援 | 伺服器端受管控 |
| 反爬處理 | 自行處理 | 自行處理 | 部分處理 | 內建 |
| 資料流程／匯出 | 內建 | 自行處理 | 內建 | 直接輸出結構化 JSON |
| 安裝複雜度 | 中等 | 起步簡單，大規模時較高 | 中等到偏高 | 極低 |
| 維護成本 | 低到中等 | 高 | 中等 | 幾乎沒有 |
| 最適合 | 大量靜態爬取 | 高互動流程 | 靜態／動態混合網站 | 已知 URL、結構化輸出 |
如果你在看這四種之外的其他爬蟲選項，也值得順手比較一下 Instant Data Scraper 替代方案 與 最佳 AI 網頁爬蟲 的表現——現在工具很多，但不是每個都解決同一個問題。
2026 年網頁爬取的法律與倫理提醒
這段我簡短帶過，因為不是本文主軸，但它很重要。Scrapy 的 ROBOTSTXT_OBEY 設定會讓你的 spider 遵守 robots.txt 規則——這是好習慣，不過也要知道，Robots Exclusion Protocol 本身就明確表示，這些規則不是法律授權。Selenium 和 Playwright 則沒有內建 robots.txt 合規機制——完全要靠你自己處理。無論你用什麼工具，抓取與重用資料前，都應先確認網站服務條款與你所在地適用法律；「資料是公開可見的」不代表在所有地區都當然合法。
為你的 2026 爬取專案選對工具
真正的關鍵其實是四個問題：內容類型是什麼、規模多大、需要多少互動、以及你願意承擔多少後續維護。大規模靜態頁面，選 Scrapy。大量 JS 且真的需要互動，選 Selenium 或 Playwright。兩者混合，就做混合架構。若是已知 URL、只要結構化輸出且希望維護最低，像 Thunderbit 這類 API 很可能比它的成本更省時。
「Scrapy vs. Selenium」從來都不是完整問題——它只是過去唯一常見的框架。Playwright 改變了中間地帶，而 AI 擷取 API 則替那些意識到自己其實是在建基礎設施、不是在解決商業問題的人，開出了一條全新的路。正式選邊站之前，先試試免費方案通常很值得——suggest-fields 是免費的，而 distill 只消耗 1 點，所以你可以先確認 API 路線適不適合，再開始寫一行 spider 程式碼。
常見問題
Scrapy 比 Selenium 更快嗎？ 以我的測試來看，是的——在靜態頁面上通常快上一個數量級，因為 Scrapy 的非同步架構完全省掉瀏覽器開銷。當 Scrapy 對重度 JS 頁面改用 Playwright middleware 時，這個差距會縮小，但在混合工作負載下，Scrapy 整體吞吐量通常還是更高，因為非 JS 頁面仍可走快速路徑。
Scrapy 可以處理 JavaScript 渲染頁面嗎？
不能只靠它自己——Scrapy 只會看到初始 HTML 回應。加入 scrapy-playwright，或較舊的 Scrapy-Splash 當作中介層，就能針對特定請求用真瀏覽器渲染，同時讓其餘爬取流程留在 Scrapy 原生、較快的路徑上。
什麼時候該用 Selenium 而不是 Scrapy？ 當你需要完整瀏覽器互動——多步驟登入、點選導引流程、填寫表單——而且頁面數量是中等而不是超大量時。若你已經有 Selenium 的測試基礎設施，也很適合拿來重用做爬取。
2026 年 Playwright 比 Selenium 更適合爬蟲嗎？ 就爬蟲用途來說，通常是的——Playwright 的效能通常更好、自動等待更完整、每個 browser context 的資源占用更輕。Selenium 仍然對那些已經在跑成熟跨瀏覽器測試套件的團隊更有優勢，因為 Playwright 並不是為了完全取代那套東西而設計的。
什麼是 AI 擷取 API？什麼時候它會取代 Scrapy 或 Selenium？ AI 擷取 API，例如 Thunderbit 的 Open API，會在伺服器端處理 JS 渲染、反爬防護與資料擷取，然後回傳你定義 schema 對應的結構化 JSON。當你手上是已知 URL，而且需要的是結構化輸出、又不想自己建或維護爬取基礎設施時，它就是對的選擇——但它不是複雜、遞迴、含自訂邏輯爬取任務中 Scrapy 的替代品。
了解更多
