自適應選擇器常常被算到錯的工具頭上。我讀過一半以上的爬蟲比較文，都把「網站改版後還能撐住」這件事，掛在某個其實做不到的大型 AI 爬蟲上。真正把這個功能放在檯面上的 Python 函式庫是 Scrapling，這個快速竄升的專案在 2026-07-09 左右已經有約 68.7k 個 GitHub stars。
所以我做了最關鍵的測試。先建立一個範例頁面、儲存一個選擇器，接著把目標元素的 class 名稱改掉——這正是網站改版後，隔天爬蟲靜悄悄整批失效的典型情況。一般選擇器回傳空值；Scrapling 的自適應比對卻還是找回了那個元素。這一點是真的，而且我會把數字拿出來看。更少人會量化的是：它到底能恢復到哪裡、又在哪裡停住，而那條界線，幾乎就是這篇評測的重點。
Scrapling 到底是什麼
Scrapling 自稱是一個能處理「從單次請求到大規模爬取」的自適應網頁爬蟲框架。把標語拿掉後，本質上就是兩個模組疊在一起：負責抓頁面的 HTTP Fetcher，以及基於 lxml 的 Selector 解析器，支援標準的 CSS/XPath，還有好用的 ::text / ::attr() 偽選擇器。它採用 BSD-3-Clause 授權，屬於相當寬鬆的開源授權。我測的是 0.4.10 版，也就是當時的最新版本，不用擔心「你拿舊版來測」這種質疑。
真正有意思的是建立在解析器之上的自適應層。可以把一般選擇器想成一個死板的地址：「抓 class 是 product-name 的元素。」只要建築重新編號——也就是 class 改名——這個地址就會指到一塊空地。Scrapling 則可以在第一次執行時替元素保存一份特徵，之後即使標記結構變動，也能根據特徵而不是失效的地址把它重新定位回來。根據 Scrapling 自適應爬取文件，比對階段會從元素的標籤、文字、屬性、兄弟節點與位置等面向計算相似度——整個過程沒有模型介入，純粹是和當初儲存的結構做比對。
這裡要先說清楚它的出身，因為這會影響你怎麼看待這個功能。自適應定位確實是個真實且有文件說明的能力，不是我自己發明的——官方文件完整寫了如何儲存到 SQLite、如何用相似度做匹配，第三方文章也有詳細介紹。自我修復選擇器的概念在測試自動化領域也早就存在。Scrapling 的特別之處在於，它把這件事當成原生函式庫功能來提供：像 lxml、parsel 和 BeautifulSoup 這類靜態解析工具只給你固定選擇器，並不會自己找回被改名的元素。所以這是一個有獨特性、也有文件佐證的功能；我做的是重現與壓力測試，不是證明世界上只有它能做到。
自適應測試的細節
測試環境是這樣搭的：我建立了一個商品目錄範例，並在元素 class 還是 product-name 的時候追蹤它。接著我把 class 改成 product-title，再用同樣的程式跑一次。一般的 .product-name 選擇器匹配到 0 個元素——這完全符合預期，因為它指向的 class 已經不存在了。Scrapling 的自適應重新比對，則利用前一版儲存的特徵把追蹤中的元素找了回來。原始結果可以在基準測試倉庫的 local_adaptive_selector.json 查看。
接下來是大多數評測都沒講清楚的部分。我把測試往前推一步，做了一個合成的多元素情境——不是一個，而是三個被追蹤的元素。結果 Scrapling 只重新定位了第一個儲存的元素，沒有全部三個。這不是失敗，也不是 bug；文件把自動匹配定義成元素追蹤，也就是每個儲存元素各自有一份特徵，所以在預設設定下出現 1/3 的結果，正是這個功能照設計運作的樣子。但這也代表，比較準確的說法應該是「具備韌性的元素追蹤」，而不是「整個改版頁面的自動恢復」。自動匹配只會跟著你指定的那個元素走；多元素韌性需要你自己另外調整。
這個差異，比乍看之下重要得多。「能撐過標記變動」是標題；「能在標記變動後持續追蹤你指定的單一特徵元素，其餘部分要你自己處理」才是你真正買到的能力。若你原本期待前者，實際用起來可能會失望；若你接受的是後者，它就能乾淨俐落地完成工作。
安裝時的坑：沒人先提醒你
這裡我真的花了不少時間，所以先講給你聽，免得你踩同樣的坑。pip install scrapling 安裝的只有解析器——而且只有解析器。當我一寫下 from scrapling.fetchers import Fetcher，就開始連環報錯：先缺 curl_cffi，接著缺 playwright，再來是 browserforge，一個接一個，都是等我解掉前一個才冒出來。
解法是安裝額外套件：pip install "scrapling[fetchers]"，或執行 scrapling install 這個 CLI 指令，把完整的 HTTP + 瀏覽器抓取堆疊一起拉下來。這樣之後就一切正常了。但「基礎安裝看起來沒問題，第一次抓取就整個爆掉」這個流程確實存在，而且一開始完全不會提醒你。從第一個指令開始就把 [fetchers] 額外套件和那些厚重的傳遞依賴算進去，你就能少走很多冤枉路。
純 HTTP 擷取的表現如何
把 fetchers 裝好之後，傳統擷取路徑表現相當穩定——召回率直接是 1.0：
| 測試 | 結果 |
|---|---|
| 靜態商品目錄 + 分頁 | 12/12 個商品 |
| 文章擷取 | 標題 + 3/3 段落 |
| 動態 JSON API | 8/8 筆資料 |
| Books to Scrape（公開頁面） | 20 個商品 |
| HTTP 500 處理 | 清楚回傳狀態碼，沒有當掉 |
lxml 的底層在這裡很明顯。CSS 和 XPath 都照你期待的方式運作，而 ::text / ::attr() 偽選擇器也讓擷取程式簡潔易讀，不會變成一串巢狀呼叫。HTTP 500 那個案例雖小，卻很有代表性——Fetcher 不是丟給我一長串堆疊追蹤，而是直接把狀態碼帶出來；這就是「可以排程執行的爬蟲」和「你必須盯著它跑」之間的差別。完整數據可以在 scrapling-test-summary.json 找到。
這些表現都不花俏，但就是對的，而「正確」其實常常被低估。
它不做什麼（而且是刻意不做）
HTTP Fetcher 不會渲染 JavaScript。我把它丟到一個由 JS 產生內容的範例頁，結果抓到 0 個卡片；在公開的 Quotes to Scrape JS page 也同樣是 0。這不是缺陷——HTTP Fetcher 只負責下載 HTML，不會啟動瀏覽器，所以客戶端渲染的內容在它看來根本不存在。Scrapling 另外提供了 DynamicFetcher（瀏覽器驅動）來處理 JS 頁面。這一輪我沒有測它，所以不會評論它的效能。只要記住：別把 HTTP 路徑拿去打客戶端渲染應用，然後期待內容自己出現。
另外還有一個 StealthyFetcher，主打反偵測。我把它視為合規議題，僅此而已——不是拿來宣傳的功能。你能在哪裡、以什麼方式爬取，取決於你的權限與法律立場；這篇評測測的是擷取能力，不是規避能力。我沒有實跑它，也不會替它評分。
優缺點整理
優點：
- 自適應選擇器確實能在 class 改名後，找回原本被一般選擇器判定為 0 的元素，這正是你會想選 Scrapling 的獨特理由。
- 在靜態頁、文章與 JSON API 上的 HTTP 擷取召回率達到 1.0。
- 基於 lxml 的 CSS/XPath 乾淨好用，
::text/::attr()偽選擇器也很易讀。 - HTTP 500 處理自然，會直接回傳狀態，不會崩潰。
- 實測版本就是最新版本，沒有版本落差問題。
- BSD-3-Clause 授權相當寬鬆，適合商業使用。
缺點：
- 自動匹配是追蹤單一儲存元素，不是整個頁面；三元素測試只找回一個。宣稱時要對準這個範圍。
pip install scrapling只會安裝解析器；fetchers 還需要[fetchers]額外套件，依賴鏈也很重，這是我親身踩過的坑。- HTTP Fetcher 不會渲染 JavaScript；客戶端內容要靠瀏覽器驅動的
DynamicFetcher，而這次沒有測。 - 這個主打韌性的功能，遇到多元素情境時仍需要手動調整。
適合誰，不適合誰
如果你在維護的爬蟲經常面對網站改版，已經受夠了某個 class 名稱一改就讓整晚擷取結果默默歸零，那 Scrapling 很值得放進工具箱。若你的痛點是「選擇器每隔幾週就壞掉，我只想讓我關心的那個元素繼續被找到」，那它就是對症下藥。即使你完全不啟用自適應層，它也能當作一個乾淨、輕量的 lxml 擷取工具，用在靜態頁面與 JSON API 上。
但有兩種情況要先調整預期，或者乾脆找別的工具。如果你以為自適應選擇器會自動修復整個改版後的頁面——它追蹤的是元素，不是重建版面——那你的思維模型就不對。再來，如果你的目標站點高度依賴 JavaScript，而你又不打算架起瀏覽器驅動的 DynamicFetcher，單靠 HTTP 路徑是不夠的。不管是哪種情況，真的要裝的話，記得從第一個指令就把 [fetchers] 額外套件加上。
托管式 AI 擷取 API 會放在哪裡
Scrapling 是免費的開源函式庫，由你自己安裝、維護與監控。程式碼、依賴關係、調校全部自己掌握，換來的是每次請求都不用付費，資料也留在內部。這是完全合理、而且很多團隊都很適合的選擇。
真正值得問的是：到底是誰來承擔「韌性」這件事。Scrapling 的答案是由你自己負責——你要替元素建立特徵、自己調整追蹤方式；而托管式 AI 擷取 API 則把這件事移到伺服器端處理。這正是 Thunderbit 的開發者方案替技術團隊補上的位置。POST /extract 會依照你定義的 JSON Schema 回傳結構化 JSON，渲染、反機器人機制與標記變動都在伺服器端吸收掉；renderMode 旗標則控制在擷取前要執行多少頁面內容。Thunderbit 也提供給 AI 代理與程式助理使用的 MCP 伺服器——thunderbit_suggest_fields 是免費功能，會先跑一次來規劃擷取欄位——另外還有可透過 npx @thunderbit/thunderbit-cli 使用的 CLI，適合終端機、腳本與 CI。三種入口背後都用同一套 AI 引擎。
真正的取捨不是誰比較好，而是你想把韌性邏輯放在哪裡。用 Scrapling，你把它留在自己的程式裡，由你自己建立特徵並調校，單次呼叫不用付費，但也必須承擔維護成本。用托管 API，則是把改版應對交出去，按請求付費。規模小、自己主機、又喜歡掌控調整細節？Scrapling 的控制感會是正解。若你要同時跑上百個網站，又不想逐一維護每個站的選擇器特徵？托管方案就能把這一大塊維運工作直接拿掉。
如果你正在比較各種方案，這份 開源爬蟲完整基準測試 會把 Scrapling 跟其他工具放在同一組測試資料上比較，而 Scrapy 評測 和 Colly 評測 也各自涵蓋了另外兩個值得參考的 HTTP 優先框架。
結論
該不該用 Scrapling？答案是：要——如果你想要一個開源的 Python 擷取工具，而它最厲害的本事，是能在底下標記變動後，依然把你追蹤的元素找回來；而且你也清楚這個能力的邊界。它確實找回了壞掉的選擇器找不到的元素，而那個改名動作，原本足以讓一般爬蟲靜悄悄流失資料。純 HTTP 擷取也很乾淨，在所有測試範例上都達到完整召回。授權寬鬆，而且我測試的版本就是最新版本。
只要你把它的能力範圍看準，通常會很滿意。它追蹤的是元素，不會自動重建頁面——三元素測試只找回一個。從一開始就把 [fetchers] 額外套件裝上，不然你就會像我一樣撞上依賴牆。如果你的頁面需要 JavaScript，那是瀏覽器驅動的 fetcher 該做的事，不是 HTTP 版本的工作。在這些界線之內，Scrapling 確實做到了它最有名的那件事；在 Python 爬蟲函式庫裡，它也是少數真的把大家常常說錯的功能做出來的工具之一。
試用 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
Scrapling 的自適應選擇器真的能撐過網站改版嗎？
能撐過針對已追蹤元素的 class 改名，這點已經實測確認。當我把 product-name 改成 product-title 後，一般選擇器匹配到 0，而自適應重新比對成功找回被追蹤的元素。但它追蹤的是已儲存元素，而不是重建整個頁面：三元素的合成測試只找回一個。比較準確的說法是韌性的元素追蹤，不是整頁自動恢復。
為什麼我 pip install scrapling 之後，匯入 fetcher 會失敗？
因為基礎安裝只有解析器。匯入 scrapling.fetchers 時，會連鎖缺少 curl_cffi、playwright、browserforge 等依賴。請改用 pip install "scrapling[fetchers]"，或執行 scrapling install CLI，把完整的 fetcher 堆疊一起裝好，匯入就能正常。
Scrapling 可以抓取 JavaScript 渲染的頁面嗎？
HTTP Fetcher 不行——在 JS 範例頁與公開的 Quotes JS 頁面上都回傳 0，因為它只下載 HTML，不會啟動瀏覽器。Scrapling 另外提供了瀏覽器驅動的 DynamicFetcher 來處理 JS 頁面；這次測試沒有涵蓋它，所以我目前還不能評論效能。
Scrapling 在一般擷取上快不快、準不準？
實測結果是準確的——在靜態商品目錄、文章頁與 JSON API 上都達到 1.0 召回率，而且基於 lxml 的 CSS/XPath 也很乾淨。它還能在 HTTP 500 時直接回傳狀態碼而不是當掉。即使你完全不用自適應層，它仍然是個穩定、輕量的靜態內容擷取工具。
Scrapling 可以商業使用嗎？
可以，它採用 BSD-3-Clause 授權，對商業使用相當友善。不過，開始正式建置前，還是建議到 repo 再確認一次目前的授權內容。
