在 GitHub 上搜尋「facebook scraper」，會出現 475 個儲存庫。但其中只有 62 個 是在過去六個月內有更新的。
這種「看起來很多，實際能用的卻很少」的落差，就是 2026 年 GitHub 上 Facebook 爬取工具的真實寫照。
我花了不少時間翻閱各個 repo 的 issue、Reddit 上的抱怨，以及這些工具實際輸出的結果。結論非常一致：大多數高星專案早就悄悄失效，維護者也不再跟進，而 Facebook 的反爬防線只會越來越強。開發者和商業使用者總是不斷點進相同的搜尋結果、安裝相同的 repo，最後也遇到相同的空白輸出。這篇文章就是一份 2026 年的現況盤點——誠實檢視哪些 repo 仍值得花時間、Facebook 用了哪些方式讓它們失效，以及什麼情況下你應該直接放棄 GitHub 方案。
為什麼大家會去 GitHub 找 Facebook Scraper
這個搜尋背後的需求其實多年來都差不多——即使工具本身一直在壞：
- 開發潛在客戶：擷取商業粉絲專頁的聯絡資訊（電子郵件、電話、地址）用於開發客戶
- Marketplace 監控：追蹤商品刊登、價格與賣家資訊，用於電商或套利
- 社群研究：保存貼文與留言，用於市場研究、OSINT 或社群管理
- 內容與貼文歸檔：儲存公開粉專貼文、互動反應、圖片與時間戳記
- 活動資料彙整：抓取活動標題、日期、地點與主辦單位
GitHub 的吸引力很明顯：程式碼可見、零成本、理論上有社群維護，而且欄位和資料流程都能完全掌控。
問題在於，星標數和分支數並不等於「現在還能用」。截至 2026 年 4 月，在星標數最高的前 10 個精確詞組 repo 中，全部 10 個都已超過 12 個月沒有更新。這不是偶發狀況，而是常態。
一位 Reddit 使用者在 2025 年 11 月的討論串 中，經過六個月嘗試後直接表示：如果不花錢買外部資料抓取應用程式，或使用 Python 加 JS 渲染再加上大量運算資源，幾乎不可能成功。另一位在 2026 年 4 月的討論 中則總結道：「Facebook 是最難爬的網站之一，因為他們會積極封鎖自動化」，而瀏覽器自動化則「很脆弱，因為 Facebook 會一直改 DOM」。
需求是真的，痛點也是真的，挫折更是真的。接下來這篇文章，就是在解開這道落差。
GitHub 上的 Facebook Scraper 到底是什麼？
GitHub 上所謂的「Facebook scraper」，通常是開源腳本——多半用 Python——用來程式化擷取 Facebook 粉專、貼文、社團、Marketplace 或個人檔案中的公開資料。它們的運作方式並不相同，主要有三種架構：
瀏覽器自動化爬蟲、API 包裝器與直接 HTTP 爬蟲
| 方式 | 常見技術堆疊 | 優勢 | 弱點 |
|---|---|---|---|
| 瀏覽器自動化 | Selenium、Playwright、Puppeteer | 可處理登入牆，模擬真實使用者行為 | 慢、資源消耗高、若設定不當很容易被指紋辨識 |
| 官方 API 包裝器 | Meta Graph API / Pages API | 穩定、文件完整、獲授權後合規 | 限制嚴格——多數公開貼文／社團資料已不可用 |
| 直接 HTTP 爬蟲 | requests、HTML 解析、未公開端點 | 成功時速度快、輕量 | Facebook 一改頁面結構或反機器人措施就會失效 |
kevinzg/facebook-scraper 是經典的直接 HTTP 範例：它透過直接請求與解析來抓取公開頁面，「不需要 API key」。apurvmishra99/facebook-scraper-selenium 則是瀏覽器自動化的例子。minimaxir/facebook-page-post-scraper 代表的是舊 Graph API 時代，當時腳本還能透過官方端點抓取粉專／社團貼文，如今這些能力已不再普遍可用。
這些 repo 通常會抓取的資料包括貼文文字、時間戳、互動／留言數、圖片網址、粉專中繼資料（類別、電話、電子郵件、追蹤者數）、Marketplace 刊登欄位，以及社團或活動中繼資料。
到了 2026 年，真正的取捨不再是語言偏好，而是你能接受哪一種失敗方式。
2026 年 Facebook Scraper GitHub 新鮮度盤點：哪些 repo 還能用？
我把 GitHub 上最熱門、也最常被推薦的 Facebook scraper repo，對照 2026 年的真實狀況做了一次盤點——不是看 README，而是看實際提交日期、issue 佇列與社群回報。這一段最重要。
完整新鮮度盤點表
| Repo | Stars | 最後更新 | 未解決 Issue | 語言 / 執行環境 | 目前還能抓什麼 | 狀態 |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | 有限的公開粉專貼文、部分留言／圖片、粉專中繼資料 | ⚠️ 部分失效／過時 |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | 與 kevinzg 類似 + Marketplace 輔助方法 | ⚠️ 部分失效／過時分支 |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Python 2/3 時代，依賴 Graph API | 僅具歷史參考價值 | ❌ 已停更 |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | 粉專抓取的瀏覽器自動化 | ❌ 已停更 |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | 透過瀏覽器自動化抓取 Marketplace 刊登 | ⚠️ 脆弱／用途狹窄 |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | 一般 Selenium 抓取 | ❌ 已停更 |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | 偏自動化用途 | ❌ 風險高／缺乏驗證 |
幾個重點很明顯：
- 即使是「還在活躍分支」的 moda20，也已經自 2024 年 6 月後沒再更新。
- issue 佇列比 README 更能快速反映真實狀態。
- kevinzg 和 moda20 的 pyproject.toml 仍寫著 Python ^3.6，代表依賴基線根本沒跟上現在的環境。
kevinzg/facebook-scraper
這是 GitHub 上最知名的 Python Facebook scraper。它的 README 說明了粉專抓取、社團抓取、使用帳密或 cookie 登入，以及貼文層級欄位如 comments、image、images、likes、post_id、post_text、text 和 time。
但實際運作訊號很弱：
- 最後更新：2024 年 6 月 22 日
- 未解決 issue： 438 —— 其中還有像「Example Scrape does not return any posts」這類標題
- 維護者近期沒有回應新的 issue
結論：部分失效。對於低量公開粉專實驗、或作為欄位名稱參考還有價值，但不適合正式生產環境。
moda20/facebook-scraper（社群分支）
這是 kevinzg 最顯眼的分支，增加了一些選項與 Marketplace 導向的輔助方法，例如 extract_listing（在其 README 中有說明）。
但它的 issue 佇列 已經把問題講得很直接：
- 「mbasic is gone」
- 「CLI 'Couldn't get any posts.'」
- 「https://mbasic.facebook.com is no longer working」
當簡化版 mbasic 前端改版或消失時，一整類爬蟲就會一起失靈。
結論：這是最值得注意的分支，但到了 2026 年也已過時且脆弱。如果你一定要走 GitHub 路線，它是最先值得試的，但別期待穩定性。
minimaxir/facebook-page-post-scraper
這曾經是非常實用的 Graph API 工具，可用來把公開粉專與開放社團的貼文、互動數、留言與中繼資料抓成 CSV。它的 README 至今仍在說明如何使用 Facebook App 的 App ID 與 App Secret。
到了 2026 年，它只是一個歷史遺跡：
- 最後更新：2019 年 5 月 23 日
- 未解決 issue：53 —— 包含「HTTP 400 Error Bad Request」與「No data retrieved!!」
結論：已停更。它緊密依賴的 API 權限模型，Meta 之後已經大幅收緊。
其他值得注意的 repo
- passivebot/facebook-marketplace-scraper：對 Marketplace 用途有幫助，但它的 issue 佇列 裡包含「login to view the content」、「CSS selectors outdated」與「Getting blocked」。這幾乎就是 Marketplace 爬取失效原因的縮影。
- apurvmishra99/facebook-scraper-selenium：有一個 issue 直接問 「Does it work with new Facebook layout?」，時間是 2020 年 9 月。這已經說明一切。
- Mhmd-Hisham/selenium_facebook_scraper 與 anabastos/faceteer：都沒有足夠新的活動，無法讓人有信心。
Facebook 的反爬防線：每個 GitHub Scraper 都在面對什麼
許多文章只會給你模糊的「記得遵守 ToS」免責聲明，這根本沒幫助。
Facebook 擁有所有大型平台中最積極的反爬系統之一。理解這些防線，才是分辨「能跑」和「整個下午都只拿到空白輸出」的關鍵。
Meta 自己在 2025 年 2 月的工程文章 中就提到，他們有一個「Anti Scraping team」，會透過對整個程式碼庫做靜態分析來找出爬取路徑、發出停止侵權函、停用帳號，並依賴速率限制系統。這不是假設，而是實際存在的組織性投入。
隨機化 DOM 與 CSS 類別名稱
Facebook 會刻意隨機化 HTML 元素 ID、class 名稱與頁面結構。正如一位 r/webscraping 留言者 所說：「沒有一般爬蟲能在 Facebook 上正常運作。HTML 每次重新整理都會變。」
會壞掉的地方：上週還能用的 XPath 和 CSS selector，今天就抓不到資料。
對策：盡量改用以文字內容或屬性為基礎的 selector。若使用 AI 解析、直接讀取頁面內容而不是依賴死板 selector，效果通常更好。但你還是得預期 selector 維護會是長期成本。
登入牆與 Session 管理
Facebook 很多區塊——像個人檔案、社團、部分 Marketplace 刊登——都需要登入才能看。無頭瀏覽器常常會被重新導向，或只拿到被簡化過的 HTML。passivebot 的 Marketplace scraper issue 區 也把「login to view the content」列為主要抱怨之一。
會壞掉的地方：匿名請求會看不到內容，甚至直接被導向別的頁面。
對策：使用真實瀏覽器 session 的 cookie，或直接採用能在登入狀態中運作的瀏覽器式抓取工具。輪換帳號雖然可行，但風險很高。
數位指紋辨識
Meta 的工程文章指出，未授權爬蟲會 「通常透過模仿使用者正常使用產品的方式來隱藏自己」，這其實等於在說：瀏覽器品質和行為品質是偵測的核心。社群在 3 月 與 2026 年 4 月 的討論中，也持續建議使用 anti-detect 瀏覽器與一致的指紋設定。
會壞掉的地方：一般現成的 Selenium 或 Puppeteer 設定很容易被辨識出來。
對策：使用像 undetected-chromedriver 這類工具，或 anti-detect 瀏覽器設定檔。真實的 session 行為與一致的指紋，比單純改 user-agent 更重要。
基於 IP 的速率限制與封鎖
Meta 的工程文章明確提到速率限制是防禦策略的一部分，甚至會限制追蹤者清單的數量，迫使更多請求出現，進而 觸發速率控制。實務上，使用者回報只要以 每 10 秒發 10 個群組貼文 就可能被限流。
會壞掉的地方：同一個 IP 的大量請求會在幾分鐘內被限速或封鎖。資料中心代理 IP 通常早就被列入黑名單。
對策：使用住宅代理輪換，而不是資料中心代理，並控制請求節奏。
GraphQL 結構變動
有些爬蟲依賴 Facebook 內部的 GraphQL 端點，因為它們回傳的結構化資料比原始 HTML 更乾淨。但 Meta 並沒有為這些內部 GraphQL 提供穩定性保證，因此這些查詢會默默失效——回傳空資料，而不是報錯。
會壞掉的地方：結構化擷取會靜悄悄地變成空值。
對策：加入驗證檢查、監控 schema 端點，並固定使用已知可行的查詢。維護是必然的。
反爬防線總結
| 防線層級 | 如何讓爬蟲失效 | 實務對策 |
|---|---|---|
| 頁面結構變動／selector 不穩定 | XPath 和 CSS selector 回傳空值或缺欄位 | 優先使用較穩定的錨點、以可見頁面輸出驗證，並預留維護成本 |
| 登入牆 | 登出狀態的請求會看不到內容或被導向 | 使用有效的 session cookie 或瀏覽器 session 工具 |
| 指紋辨識 | 標準自動化看起來太像機器人 | 使用真實瀏覽器、保持一致的 session 品質、採取 anti-detect 措施 |
| 速率限制 | 空白輸出、封鎖、限流 | 降低速度、縮小批次、輪換住宅代理 |
| 內部查詢變更 | 結構化擷取默默回傳空資料 | 加入驗證檢查，並預期查詢需要維護 |
當 GitHub Repo 失效時：改用合法授權的替代方案
repo 壞掉，不代表你就該想辦法繞過平台控制。先釐清商業問題：你需要的是粉專層級分析、廣告透明度、公開聯絡人名錄，還是商品目錄？很多需求其實都能透過官方 Meta 產品、授權 API，或非 Meta 的公開資料來源來滿足。
例如：只有在應用程式與使用情境具有必要權限時，才使用 Graph API；只有符合資格時，才使用 Meta 的研究計畫；廣告資訊則使用 Meta Ad Library。若是開發潛在客戶、價格調查或在地商家搜尋，通常更適合選擇你可以直接審查條款與隱私義務的獨立公開網站。
真實輸出範例：你實際會拿到什麼
很多競品文章只會放程式碼範例，卻不會展示真正的輸出。以下是你可以合理期待的結果。
範例輸出：kevinzg/facebook-scraper（或活躍分支）
根據 README 範例，抓到的公開貼文 JSON 會像這樣：
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
注意像 comments_full 這種可為空的欄位。到了 2026 年，你應該預期更多欄位會回傳空值或缺失——這通常不是小故障，而是被阻擋的訊號。輸出是原始 JSON，還需要後續處理。
範例輸出：Facebook Graph API
Meta 目前的 Pages API 文件說明了粉專資訊查詢，例如 GET /<PAGE_ID>?fields=id,name,about,fan_count。 Page 參考文件 則包含 followers_count、fan_count、category、emails、phone 等公開中繼資料——但前提是你要具備正確權限，例如 Page Public Content Access 或 Page Public Metadata Access。
這和多數 GitHub scraper 使用者預期的資料形狀差很多。它以粉專為中心、受權限控管，不能取代任意公開貼文或社團抓取。
Facebook 資料類型 × 取得路徑對照表
| Facebook 資料類型 | 建議起點 | 主要限制 |
|---|---|---|
| 由你組織管理的資產 | 官方 Meta 管理工具與已核准 API | 權限與可用欄位會因情境而異 |
| 廣告觀察資料 | Meta Ad Library | 只能使用它公開提供的欄位與篩選條件 |
| 開發潛在客戶所需的公開商家資訊 | 允許使用的非 Meta 名錄或發布者網站 | 需自行確認來源條款與隱私義務 |
| 私密、封閉社團、登入後才看得到，或僅限帳號存取的內容 | 不要自動化蒐集 | 改走授權路徑 |
步驟教學：如何從 GitHub 設定 Facebook Scraper（如果真的值得做）
如果你看完新鮮度盤點後，還是想走 GitHub 路線，也可以。以下是實務流程——我會老實說明容易壞掉的地方。
步驟 1：選對 repo（先看新鮮度盤點）
先回頭看上面的盤點表。選擇最不過時、且符合你目標頁面的 repo。在安裝任何東西之前，先看 Issues 分頁——近期 issue 的標題，比 README 更能反映真實可用性。
步驟 2：建立 Python 環境
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
常見坑點：依賴版本衝突，尤其是 Selenium／Playwright 版本。kevinzg 和 moda20 在 pyproject.toml 中都寫著 Python ^3.6，這是一個較舊的基準，可能會和新版本函式庫衝突。passivebot 的 Marketplace scraper 則把 playwright==1.40.0 鎖版本，這對實驗來說沒問題，但不能證明它有長期穩定性。
步驟 3：設定代理與反偵測
如果你做的不只是快速測試：
- 建立住宅代理輪換（找有 Facebook 專用 IP 池的供應商）
- 若使用瀏覽器自動化，安裝 undetected-chromedriver 或設定反指紋方案
- 不要跳過這步——一般 Selenium 或 Puppeteer 很快就會被標記
步驟 4：先跑小規模測試並驗證輸出
從單一公開粉專開始，不要一開始就批次大量抓取。仔細檢查輸出：
- 欄位空白或資料缺失，通常代表 Facebook 的防線正在擋你
- 把結果和你在瀏覽器中實際看到的頁面內容對照
- 一次成功的小測試，比一份好看的 README 更重要
步驟 5：處理錯誤、速率限制與維護
- 加入重試邏輯與錯誤處理
- 預期要定期更新 selector 或設定——這是持續維護，不是一次搞定就能放著不管
- 如果你發現自己花在維護爬蟲的時間，比使用資料還多，這就是該重新考慮無程式碼方案的訊號
Facebook 爬取的法律與倫理注意事項
平台條款、隱私規範、合約義務與資料保護法都可能適用。可公開瀏覽，不代表可以自動化擷取。請盡量最小化資料蒐集、記錄用途與合法依據，若涉及商業或大規模計畫，請尋求法律建議。
不要把瀏覽器擴充功能、登入狀態或「公開」標籤，當成可以自動蒐集 Meta 產品資料的授權。
重點結論：2026 年 Facebook Scraping 到底什麼可行
repo 活動度、issue 佇列與平台現行規則，比星標數或舊 README 更重要。當業務問題是你自己管理的資產時，請先從官方 Meta 工具與已核准 API 著手。若是市場研究、開發潛在客戶或價格比較，允許使用的非 Meta 資料源通常更容易治理與文件化。
常見問題
2026 年 GitHub 上還有能用的 Facebook scraper 嗎？
有，但選擇很少。最值得注意的是 kevinzg 原始 repo 的 moda20/facebook-scraper 分支——可參考上方的新鮮度盤點表了解目前狀態。它可以部分抓取公開粉專貼文與部分中繼資料，但 issue 佇列顯示 mbasic 和空白輸出的核心問題仍然存在。其他大多數 repo 不是已停更，就是完全壞掉。
我可以不用寫程式就抓 Facebook 嗎？
若只是人工研究，可使用 Facebook 自己的搜尋和管理工具。若要重複執行或程式化處理，請評估官方 API 與其權限，或重新設計流程，改用允許的非 Meta 資料來源。無程式碼只是方便，不代表可以免除平台、隱私或合約義務。
抓 Facebook 合法嗎？
Facebook 的 服務條款 禁止未經許可的自動資料蒐集。Meta 也會透過停權、停止侵權函與 訴訟 積極執行。合法性會因司法管轄區與用途而異。請盡量使用公開的商業資料、避免個人檔案，若要大規模操作，請諮詢法律顧問。
Facebook Graph API 現在還能拿到哪些資料？
到了 2026 年，Graph API 已經受到高度限制。你可以在具備正確權限的情況下，存取有限的粉專層級資料——例如 id、name、about、fan_count、emails、phone，像是 Page Public Metadata Access 這類權限。但大多數公開貼文資料、社團資料（Groups API 已停用）以及使用者層級資料，現在都無法再透過 API 取得。
Facebook scraper GitHub repo 多久會壞一次？
很頻繁。Facebook 會持續調整 DOM 結構、反機器人措施與內部 API，雖然沒有公開固定週期，但社群回報顯示，活躍爬蟲大約每隔幾週就可能壞一次。moda20 分支中關於 mbasic 消失的 issue 佇列，就是近期例子。如果你依賴 GitHub repo，請預留持續維護與輸出驗證的成本。
延伸閱讀
