Facebook 爬蟲 GitHub：哪些還能用，哪些已經不行

在 GitHub 上搜尋「facebook scraper」，會出現 。但只有 是在過去六個月內還有更新。

這種「看起來很多專案可用」和「實際真的能跑」之間的落差，就是 2026 年 GitHub 上 Facebook 爬蟲的全部故事。

我花了很多時間翻查各個儲存庫的 issue 分頁、Reddit 抱怨串，以及這些工具實際輸出的結果。模式很一致：多數高星專案其實早就悄悄壞掉，維護者也早已轉向別的項目，而 Facebook 的反爬防線則越來越強。開發者和商業使用者不斷進到同樣的搜尋結果、安裝同樣的 repo，最後拿到的也是同樣的空白輸出。這篇文章是 2026 年的現實檢視——誠實盤點哪些 repo 仍值得花時間、Facebook 正在怎麼破解它們，以及你什麼時候該直接跳過 GitHub。

為什麼大家會在 GitHub 上找 Facebook 爬蟲

這個搜尋背後的用途，其實和多年來一樣——即使工具本身一直在失效：

• 開發潛在客戶：擷取商業粉專的聯絡資訊（電子郵件、電話、地址）用於外聯
• 商城監控：追蹤商品刊登、價格與賣家資訊，用於電商或套利
• 社團研究：封存貼文與留言，用於市場研究、OSINT 或社群管理
• 內容與貼文封存：保存公開粉專貼文、互動反應、圖片與時間戳記
• 活動彙整：抓取活動標題、日期、地點與主辦者

GitHub 的吸引力很明顯：程式碼看得見、零成本、理論上有社群維護，而且對欄位與資料流程有完整控制權。

問題在於，星號和 fork 數，並不等於「現在真的能用」。以 2026 年 4 月來看，在 stars 前 10 名、且搜尋字串完全符合的 repo 裡，。這不是偶發，而是常態。

一位 Reddit 使用者在一個 裡，試了六個月後直白地表示：如果不是付費買外部資料擷取工具，就是得用 Python 加 JS 渲染，再加上不小的運算資源，幾乎不可能成功。另一位在 裡總結得更直接：「Facebook 是最難爬的之一，因為他們會積極封鎖自動化」；而瀏覽器自動化則「很脆弱，因為 Facebook 會一直改 DOM」。

需求是真的。痛點也是真的。接下來這篇文章，就是在處理這個落差。

什麼才算是 GitHub 上的 Facebook 爬蟲 Repo？

GitHub 上所謂的「Facebook 爬蟲」，通常是開源腳本——大多用 Python——用程式化方式擷取 Facebook 的公開資料，例如粉專、貼文、社團、Marketplace 或個人檔案。不過它們的運作方式並不相同，主要有三種架構：

瀏覽器自動化爬蟲 vs. API Wrapper vs. 直接 HTTP 爬蟲

是經典的直接 HTTP 範例：它用直接請求和解析的方式，抓取公開頁面資料，「不需要 API key」。 則是瀏覽器自動化範例。 代表的是舊 Graph API 時代，當時腳本還能透過官方端點抓取粉專／社團貼文，而這些端點現在已經不再廣泛可用。

這些 repo 常見的目標資料包括貼文文字、時間戳記、互動／留言數、圖片 URL、粉專中繼資料（類別、電話、電子郵件、粉絲數）、Marketplace 刊登欄位，以及社團或活動中繼資料。

到了 2026 年，真正的取捨已經不是語言偏好，而是你能接受哪一種失敗。

2026 年 Facebook 爬蟲 GitHub 新鮮度檢查：哪些 Repo 真的還能用？

我把 GitHub 上最熱門、最常被推薦的 Facebook 爬蟲 repo，拿 2026 年的真實狀況來檢查——不是看 README 宣稱，而是看實際提交日期、issue 佇列與社群回報。這一段最重要。

完整新鮮度檢查表

幾件事一眼就看得出來：

• 就算是「活躍 fork」（moda20），也已經自 2024 年 6 月後沒再推送。
• issue 佇列比 README 更能快速看出真相。
• kevinzg 與 moda20 在各自的 裡仍宣告 Python ^3.6，這代表依賴基線幾乎沒有現代化。

kevinzg/facebook-scraper

這是 GitHub 上最知名的 Python Facebook 爬蟲。它的 描述了粉專爬取、社團爬取、透過帳密或 cookies 登入，以及 comments、image、images、likes、post_id、post_text、text、time 等貼文層級欄位。

但從實際運作訊號來看，情況偏弱：

• 最後推送：2024 年 6 月 22 日
• 開啟中的 issue： ——其中包含像「Example Scrape does not return any posts」這類標題
• 維護者近期沒有回應新的 issue

結論：部分壞掉。對小量公開粉專實驗，或拿來參考欄位名稱，還有價值；但不適合生產環境。

moda20/facebook-scraper（社群 Fork）

這是 kevinzg 最顯眼的 fork，增加了一些選項與偏向 Marketplace 的輔助功能，例如 extract_listing（在它的 中有說明）。

它的 直接把壞掉的原因寫得很清楚：

• 「mbasic 不見了」
• 「CLI 顯示『Couldn’t get any posts.』」
• 「https://mbasic.facebook.com 已經不能用了」

當簡化版 mbasic 前端改版或消失，整個類型的爬蟲就會一起失效。

結論：這是最值得注意的 fork，但在 2026 年也同樣過時且脆弱。如果你堅持要用 GitHub 方案，它是第一個可以試的，但不要期待穩定性。

minimaxir/facebook-page-post-scraper

這曾經是非常實用的 Graph API 工具，可把公開粉專與開放社團中的貼文、互動、留言與中繼資料匯出成 CSV。它的 到現在仍在說明如何使用 Facebook app 的 App ID 與 App Secret。

到了 2026 年，它只是歷史遺物：

• 最後推送：2019 年 5 月 23 日
• 開啟中的 issue：53——其中包括「HTTP 400 Error Bad Request」與「No data retrieved!!」

結論：已停止維護。它高度依賴一個 Meta 之後大幅收緊的 API 權限模型。

其他值得注意的 Repo

• passivebot/facebook-marketplace-scraper：對 Marketplace 用途有幫助，但它的 包含「登入後才能看內容」、「CSS selector 過時」與「被封鎖了」。這幾乎就是 Marketplace 爬取會壞掉的縮影。
• apurvmishra99/facebook-scraper-selenium：它有一個 issue 直接問 ，而且是 2020 年 9 月的。這其實已經說明了大半。
• Mhmd-Hisham/selenium_facebook_scraper 與 anabastos/faceteer：目前活躍度都不足，沒辦法讓人有信心。

Facebook 的反爬防線：每個 GitHub 爬蟲都在對抗什麼

多數相關文章只會給你空泛的「注意 ToS」免責聲明。那沒有幫助。

Facebook 是大型平台中最積極反爬的系統之一。了解它的防線層級，才分得清一個爬蟲是可用，還是只會產出一下午的空白結果。

Meta 自己在 裡就描述了他們的「Anti Scraping team」：透過對整個程式碼庫做靜態分析來找出爬取向量、發送停止侵權通知、停用帳號，並依賴限流系統。這不是假設，而是明確的組織策略。

隨機化 DOM 與 CSS 類別名稱

Facebook 會刻意隨機化 HTML 元素 ID、class 名稱與頁面結構。正如一位 所說：「沒有正常的爬蟲能在 Facebook 上運作。HTML 會在重新整理之間變來變去。」

會壞掉的地方：上週還能用的 XPath 和 CSS selector，今天就抓不到任何東西。

應對方式：盡可能使用以文字或屬性為基礎的 selector。能讀頁面內容、而不是只靠死板 selector 的 AI 解析，通常會好一些。selector 的維護，要當成持續成本。

登入牆與 Session 管理

許多 Facebook 版面——個人檔案、社團、部分 Marketplace 刊登——都需要登入才能看。無頭瀏覽器常常會被重新導向，或只拿到縮減版 HTML。passivebot 的 Marketplace 爬蟲 中，最常見的抱怨之一就是「登入後才能看內容」。

會壞掉的地方：匿名請求會看不到內容，或直接被重新導向。

應對方式：使用真實瀏覽器工作階段的 session cookies，或使用可在已登入 session 內運作的瀏覽器型爬取工具。輪換帳號雖然可行，但風險很高。

數位指紋辨識

Meta 的工程文章提到，未經授權的爬蟲 ，這等於是明說：瀏覽器品質與行為品質是偵測的核心。社群在 與 的討論，也持續建議使用 anti-detect 瀏覽器與一致的指紋。

會壞掉的地方：標準現成的 Selenium 或 Puppeteer 設定很容易被辨識。

應對方式：使用 undetected-chromedriver 或 anti-detect 瀏覽器設定檔。真實的 session 與一致的指紋，比單純偽裝 user-agent 更重要。

基於 IP 的限流與封鎖

Meta 的工程文章明確提到限流是防線的一部分，甚至包括限制粉絲清單數量，迫使更多請求進而 。實務上，使用者回報在 後就被限流。

會壞掉的地方：來自同一個 IP 的大量請求，幾分鐘內就可能被降速或封鎖。資料中心代理 IP 往往早就被擋。

應對方式：住宅代理輪換（不要用資料中心代理），並控制請求節奏。

GraphQL Schema 變更

有些爬蟲依賴 Facebook 內部的 GraphQL 端點，因為它們回傳的結構化資料比原始 HTML 更乾淨。但 Meta 不會對內部 GraphQL 提供穩定性保證，所以這些查詢常常是靜默失效——回傳空資料而不是錯誤。

會壞掉的地方：結構化擷取會默默回傳空結果。

應對方式：加上驗證檢查、監控 schema 端點，並固定在已知可用的 query。你需要預期後續維護。

反爬防線總結

當 GitHub Repo 失效時：無程式碼的替代方案

搜尋「facebook scraper github」而來的人，很多根本不是開發者。他們可能是想找商業粉專電子郵件的業務、追蹤 Marketplace 價格的電商營運，或是做競品研究的行銷人。他們不想管理 Python 環境、除錯壞掉的 selector，或處理代理輪換。

如果這很像你，決策路徑其實很短：

擷取 Facebook 粉專聯絡資訊（電子郵件、電話）

如果你的工作只是從粉專「關於」區塊抓電子郵件和電話，那 GitHub repo 就太大材小用了。 的免費 與 可以掃描網頁，並把結果匯出到 Sheets、Excel、Airtable 或 Notion。AI 每次都會重新讀取頁面，所以 Facebook 的 DOM 變動不會把它弄壞。

擷取 Marketplace 或商業頁面的結構化資料

如果你要抓商品刊登、價格、地點或商家細節，Thunderbit 的人工智慧網頁爬蟲可以讓你點選「AI 建議欄位」——AI 會讀取頁面並提議像價格、標題、地點這類欄位——然後再按「開始抓取」。不需要維護 XPath，也不用安裝程式碼。可直接匯出到 。

排程監控（Marketplace 價格提醒、競品追蹤）

如果你要持續監控——例如「當 Marketplace 刊登符合我的價格區間時提醒我」——Thunderbit 的 允許你用自然語言描述間隔（例如 ）並設定網址。它會自動執行，不需要 cron job。

什麼時候 GitHub Repo 仍然是正確選擇

如果你需要深度程式控制、大規模擷取，或客製化資料管線，GitHub repo（或用於結構化擷取的 ）才是合適工具。選擇很直接：有簡單擷取需求的商業使用者 → 先用無程式碼；正在打造資料管線的開發者 → GitHub repo 或 API。

真實輸出範例：你實際會拿到什麼

每篇競品文章都會秀程式碼片段，卻很少展示真正的輸出。下面是你可以合理期待的結果。

範例輸出：kevinzg/facebook-scraper（或活躍 fork）

根據 ，抓到的公開貼文會回傳類似這樣的 JSON：

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "Don't let this diminutive version...",
9  "text": "Don't let this diminutive version...",
10  "time": "2019-04-30T05:00:01"
11}

請注意像 comments_full 這樣可為空的欄位。到了 2026 年，更多欄位很可能會變成空值或缺失——這通常是被擋住的訊號，而不是無害的小故障。這種輸出是原始 JSON，還需要後續處理。

範例輸出：Facebook Graph API

Meta 目前的 文件中，會說明像 GET /<PAGE_ID>?fields=id,name,about,fan_count 這種頁面資訊請求。 則包含 followers_count、fan_count、category、emails、phone 與其他公開中繼資料——但前提是你要有正確權限，例如 。

這種資料形狀遠比多數 GitHub 爬蟲使用者預期的更狹窄。它是以粉專為中心、受權限管控，而且不能替代任意公開貼文或社團爬取。

範例輸出：Thunderbit 人工智慧網頁爬蟲

Thunderbit 為 Facebook 商業頁面所建議的欄位，會產出乾淨、結構化的表格：

對於貼文與留言，輸出會像這樣：

結構化欄位、格式化電話號碼、可直接使用的資料——完全不需要後處理。這和 GitHub 工具吐出的原始 JSON 形成鮮明對比。

Facebook 資料類型 × 最佳工具對照表

2026 年，沒有任何單一工具能把 Facebook 的所有情境都處理得很好。

這張對照表可以讓你直接跳到自己的用途，而不用把整篇文章看完再找答案。

哪種方法適合你的團隊？

• 做業務開發的銷售團隊：先從 Thunderbit 的郵箱／電話提取器或人工智慧爬蟲開始。免設定，立刻有結果。
• 監控 Marketplace 的電商團隊：用 Thunderbit 的排程爬蟲，或自訂 Scrapy + 住宅代理架構（如果你有工程資源）。
• 打造資料管線的開發者：GitHub repo（活躍 fork）+ 住宅代理 + 維護預算。要有持續工作的心理準備。
• 封存社團內容的研究人員：只能用瀏覽器型工作流程（Thunderbit 或帶登入的 Selenium），並先做合規審查。

誠實地說——也是 ——根本沒有單一可靠的解法。你需要把特定資料需求對應到正確工具。

逐步教學：如何從 GitHub 設定 Facebook 爬蟲（如果這樣做有意義）

如果你看完新鮮度檢查後，還是想走 GitHub 路線，那也沒問題。下面是實際可行的流程——同時也誠實標註哪些地方最容易壞。

步驟 1：選對 Repo（使用新鮮度檢查表）

回頭看那張檢查表。選擇最不過時、且符合你目標頁面的 repo。在安裝任何東西之前，先看 Issues 分頁——最新的 issue 標題，比 README 更能反映現況。

步驟 2：設定你的 Python 環境

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

常見陷阱：依賴套件版本衝突，尤其是 Selenium／Playwright 版本。kevinzg 與 moda20 都在各自的 中宣告 Python ^3.6——這是較舊的基線，可能與較新的函式庫衝突。passivebot 的 Marketplace 爬蟲把 鎖定住了，做實驗沒問題，但不能證明它夠耐用。

步驟 3：設定代理與反偵測

如果你要做的不只是快速測試：

• 設定住宅代理輪換（找有 Facebook 專用 IP 池的供應商）
• 如果用瀏覽器自動化，安裝 undetected-chromedriver 或配置反指紋偵測
• 不要跳過這一步——標準 Selenium 或 Puppeteer 很快就會被標記

步驟 4：先跑小規模測試爬取並驗證輸出

先從單一公開粉專開始，不要一開始就大量批次。仔細檢查輸出：

• 空欄位或缺失資料，通常表示 Facebook 的防線正在擋你
• 把輸出和你在瀏覽器裡實際看到的內容對照
• 一次成功的單頁測試，比漂亮的 README 更重要

步驟 5：處理錯誤、限流與後續維護

• 建立重試邏輯與錯誤處理
• 預期要定期更新 selector 或設定——這是持續維護，不是一次設定就放著
• 如果你發現自己花在維護爬蟲上的時間，比使用資料還多，那就是該重新考慮無程式碼方案的訊號

Facebook 爬取的法律與倫理考量

這一節很短，也很直接。它不是本文的重點，但如果完全不提，就不負責任了。

Facebook 的 明確寫道，使用者「不得在未事先取得許可的情況下，以自動化方式存取或收集我們產品中的資料」。Meta 的 （2026 年 2 月 3 日更新）也清楚說明，執行措施可能包括停權、移除 API 存取，以及帳號層級的處置。

這不是紙上談兵。Meta 在 裡描述了對未授權爬取的主動調查、停止侵權通知與帳號停用。Meta 也曾對爬蟲公司採取 ，例如 Voyager Labs 訴訟。

最安全的理解方式是：

• Meta 條款明確反對爬取
• 取得授權的 API 用法，比未授權爬取安全得多
• 公開可見，不代表就不受隱私法約束（GDPR、CCPA 等）
• 如果規模較大，請諮詢法律顧問
• Thunderbit 是為抓取公開可得資料而設計，使用雲端爬取時不會繞過登入要求

重點結論：2026 年 Facebook 爬取到底什麼能用

到了 2026 年，多數 Facebook 爬蟲 GitHub repo 都已壞掉或不可靠。這不是危言聳聽——而是提交日期、issue 佇列與社群回報一致顯示的結果。

少數還活著的 fork 仍能處理有限的公開粉專資料，但它們需要持續維護、反偵測設定，以及對「東西還會再壞」的現實預期。Graph API 有用，但範圍很窄——它覆蓋的是具備正確權限的粉專層級中繼資料，不是多數人想要的大量公開貼文或社團爬取。

對於不想承擔開發者成本的商業使用者來說，像 這類無程式碼工具，提供的是更可靠、維護成本更低的路徑。AI 會每次重新讀取頁面，所以 DOM 變動不會弄壞你的流程。你可以免費試用 ，並匯出到 Sheets、Excel、Airtable 或 Notion。

實際建議很簡單：先看新鮮度檢查表。如果你不是開發者，先試無程式碼方案。如果你是開發者，只有在你真的有技術資源——以及耐心——去維護它時，才值得投資 GitHub 方案。不管你選哪條路，都應該把特定資料需求對應到正確工具，而不是期待某個萬能解法能包辦一切。

如果你想更深入了解社群媒體資料爬取與相關工具，我們有關於 、 與 的指南。你也可以在 觀看操作教學。

常見問題

2026 年 GitHub 上還有可用的 Facebook 爬蟲嗎？

有，但選擇很有限。最值得注意的是 kevinzg 原始 repo 的 fork——請查看上方的新鮮度檢查表確認目前狀態。它可以部分抓取公開粉專貼文和一些中繼資料，但 issue 佇列顯示 mbasic 和空白輸出等核心問題仍未解決。多數其他 repo 不是已停止維護，就是完全壞掉。

我可以不寫程式就爬 Facebook 嗎？

可以。 以及免費的電子郵件／電話提取器，讓你只要幾個點擊，就能直接從瀏覽器擷取 Facebook 資料，不需要 Python 或 GitHub 設定。AI 每次都會重新讀頁，因此 Facebook 改版時，你也不用維護 selector。

爬 Facebook 合法嗎？

Facebook 的 禁止未經許可的自動化資料收集。Meta 也會透過封號、停止侵權通知與 積極執法。合法性會因法域與用途而異。請只針對公開可得的商業資料，避免個人檔案；若規模較大，請諮詢法律顧問。

Facebook Graph API 現在還能拿到哪些資料？

到了 2026 年， 已被高度限制。你可以在具備適當權限（例如 ）的情況下，存取有限的粉專層級資料——例如 id、name、about、fan_count、emails、phone。但多數公開貼文資料、社團資料（）以及使用者層級資料，已不再能透過 API 取得。

Facebook 爬蟲 GitHub repo 多久會壞一次？

很常。Facebook 會持續改變其 DOM 結構、反機器人機制與內部 API——雖然沒有公開固定頻率，但社群回報顯示，活躍爬蟲大約每隔幾週就可能失效一次。moda20 fork 因 mbasic 消失而產生的 issue 佇列，就是最近的例子。如果你依賴 GitHub repo，請把定期維護與輸出驗證納入預算。

延伸閱讀