Facebook 爬虫 GitHub：哪些还能用，哪些已经不行了

在 GitHub 上搜索“facebook scraper”会返回 。其中只有 在过去六个月内有过更新。

“有仓库”和“真能用”之间的巨大落差，就是 2026 年 GitHub 上 Facebook 爬取工具的全部故事。

我花了很多时间翻看仓库的 Issue 区、Reddit 抱怨贴，以及这些工具实际跑出来的结果。模式非常一致：大多数高星项目都在悄悄失效，维护者早已不再跟进，而 Facebook 的反爬防线却越来越强。开发者和业务用户一次又一次搜到同样的结果，装上同样的仓库，最后得到的也是同样的空输出。本文就是一次 2026 年的现实检验——诚实盘点哪些仓库还值得你花时间、Facebook 正在用什么方式让它们失效，以及什么时候你应该直接跳过 GitHub。

为什么大家会去 GitHub 上找 Facebook 爬虫

这类搜索背后的需求其实很多年都没变——哪怕工具本身一直在坏：

• 线索开发：提取企业主页的联系信息（邮箱、电话、地址）用于外联
• 电商监控：跟踪商品列表、价格和卖家信息，用于电商或套利
• 群组研究：归档帖子和评论，用于市场研究、OSINT 或社群管理
• 内容与帖子归档：保存公开主页帖子、互动、图片和时间戳
• 活动聚合：抓取活动标题、日期、地点和组织者

GitHub 的吸引力很明显：代码可见、零成本、理论上有社区维护，还能完全掌控字段和管道。

问题在于，星标数和 Fork 数并不等于“当前能用”。截至 2026 年 4 月，在星标最高的前 10 个精确短语仓库里，。这不是偶然，而是常态。

一位 Reddit 用户在一篇 里，经过六个月尝试后直言不讳：如果不用“付费的外部数据抓取应用”，或者 Python 加上 JS 渲染再加大量算力，几乎不可能搞定。另一位用户在 里总结得更直接：“Facebook 是最难抓取的平台之一，因为它会积极阻止自动化”，而浏览器自动化“又很脆弱，因为 Facebook 会不断改 DOM。”

需求是真实的。痛点也是真实的。接下来这篇文章，就是帮你跨过这道鸿沟。

GitHub 上的 Facebook 爬虫仓库，到底是什么？

GitHub 上的“Facebook 爬虫”，通常是一段开源脚本——多半是 Python——用于程序化提取 Facebook 页面、帖子、群组、Marketplace 或个人主页中的公开数据。它们的工作方式并不相同，主要有三种架构：

浏览器自动化爬虫 vs API 封装 vs 直接 HTTP 爬虫

是经典的直接 HTTP 示例：它通过直接请求和解析，在“不需要 API key”的情况下抓取公开页面。 则是浏览器自动化示例。 代表的是旧 Graph API 时代，那时候脚本还能通过官方端点拉取页面/群组帖子，而这些端点如今已不再广泛可用。

这些仓库通常会抓取的目标数据包括帖子正文、时间戳、互动/评论数、图片 URL、页面元信息（分类、电话、邮箱、粉丝数）、Marketplace 商品字段，以及群组或活动元数据。

到了 2026 年，真正的取舍已经不是语言偏好，而是你能容忍哪种失败。

2026 年 Facebook 爬虫 GitHub 鲜活度审计：哪些仓库真的还在工作？

我把 GitHub 上最热门、最常被推荐的 Facebook 爬虫仓库，拿 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 ID 和 App Secret。

到了 2026 年，它已经成了历史遗留物：

• 最后更新：2019 年 5 月 23 日
• 未关闭 Issue：53——包括“HTTP 400 Error Bad Request”和“No data retrieved!!”

结论：已放弃。它强依赖一个 Meta 之后大幅收紧的 API 权限模型。

其他值得注意的仓库

• passivebot/facebook-marketplace-scraper：对 Marketplace 场景有用，但它的 里包括“login to view the content”、“CSS selectors outdated”和“Getting blocked”。这几乎就是 Marketplace 抓取会坏在哪里的单行案例。
• apurvmishra99/facebook-scraper-selenium：它有一个问题标题直接问 ，时间是 2020 年 9 月。基本说明了一切。
• Mhmd-Hisham/selenium_facebook_scraper 和 anabastos/faceteer：当前活跃度都不够，没法建立信心。

Facebook 的反爬防线：每个 GitHub 爬虫都在对抗什么

大多数相关文章只会给出空泛的“注意 ToS”免责声明。这没有用。

Facebook 拥有所有主流平台里最激进的反爬系统之一。理解这些具体防线，决定了你拿到的是一个能用的爬虫，还是一个下午都在产出空结果的工具。

Meta 自己在 里描述了一个“Anti Scraping team”，他们会在整个代码库中做静态分析来识别爬取向量，发送停止侵权函、禁用账号，并依赖限流系统。这不是假设，而是组织层面的持续投入。

随机化 DOM 与 CSS 类名

Facebook 会刻意随机化 HTML 元素 ID、类名和页面结构。正如一位 所说：“没有普通爬虫能在 Facebook 上正常工作。HTML 在刷新之间都会变。”

会坏什么：上周还有效的 XPath 和 CSS 选择器，今天就返回空结果。

应对办法：尽可能使用基于文本或属性的选择器。AI 驱动的解析如果是读取页面内容，而不是依赖死板选择器，通常会更稳。把选择器维护当成长期成本。

登录墙与会话管理

很多 Facebook 页面——比如个人主页、群组、部分 Marketplace 列表——都要求登录后才能看。无头浏览器往往会被重定向，或者只拿到简化版 HTML。passivebot Marketplace 爬虫的 里，“login to view the content”就是高频抱怨。

会坏什么：匿名请求拿不到内容，或者直接被重定向走。

应对办法：使用真实浏览器会话中的 session cookies，或者直接用运行在已登录会话里的浏览器型抓取工具。轮换账号也可行，但风险很高。

数字指纹识别

Meta 的工程博客提到，未授权爬虫，这实际上是在说：浏览器质量和行为质量是检测的核心。社区在 和 的讨论里，仍然在推荐 anti-detect 浏览器和一致性的指纹。

会坏什么：标准的 Selenium 或 Puppeteer 现成配置很容易被识别出来。

应对办法：使用 undetected-chromedriver 或 anti-detect 浏览器配置文件。真实会话和一致的指纹，比单纯伪装 user-agent 更重要。

基于 IP 的限流与封锁

Meta 的工程博客明确把限流列为防线的一部分，包括限制关注者列表的数量，迫使请求次数增加，从而触发。实际使用中，用户反馈在 后就开始被限流。

会坏什么：来自同一 IP 的批量请求会在几分钟内被降速或封锁。数据中心代理 IP 往往在一开始就被拦。

应对办法：使用住宅代理轮换，而不是数据中心代理，并控制合理的请求节奏。

GraphQL 架构变更

有些爬虫依赖 Facebook 的内部 GraphQL 端点，因为它们返回的结构化数据比原始 HTML 更干净。但 Meta 并没有对内部 GraphQL 提供稳定性保证，所以这些查询会悄悄失效——返回空数据，而不是报错。

会坏什么：结构化提取会静默返回空结果。

应对办法：增加校验检查，监控 schema 端点，并锁定到已知可用的查询。要接受持续维护。

反爬防线总结

当 GitHub 仓库失效时：无代码替代方案

很多搜索“facebook scraper github”的人其实不是开发者。他们可能是想找企业主页邮箱的销售、监控 Marketplace 价格的电商运营，或者做竞品研究的市场人员。他们不想维护 Python 环境、调试坏掉的选择器，或者轮换代理。

如果这说的就是你，决策路径其实很短：

抓取 Facebook 主页联系信息（邮箱、电话）

如果任务只是从主页“关于”部分提取邮箱和电话号码，那用 GitHub 仓库就太重了。 的免费 和 可以扫描网页，并把结果导出到 Sheets、Excel、Airtable 或 Notion。AI 每次都会重新读取页面，所以 Facebook DOM 变化不会把你弄坏。

从 Marketplace 或企业主页抓取结构化数据

如果你要提取商品列表、价格、位置或企业详情，Thunderbit 的 AI 网页爬虫可以让你点击“AI Suggest Fields”——AI 会读取页面并建议诸如价格、标题、位置之类的列，然后你再点“Scrape”。不用维护 XPath，不用安装代码。可直接导出到 。

定时监控（Marketplace 价格提醒、竞品跟踪）

如果你要持续监控——比如“当某个 Marketplace 列表符合我的价格区间时提醒我”——Thunderbit 的 可以让你用自然语言描述间隔（比如 ），再设置 URL。它会自动运行，不需要 cron 作业。

什么时候 GitHub 仓库仍然是正确选择

如果你需要深度程序控制、大规模提取，或自定义数据管道，那么 GitHub 仓库（或者用于结构化提取的 ）仍然是合适工具。决策很简单：业务用户、只需要简单提取 → 先无代码；开发者、要搭建数据管道 → GitHub 仓库或 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": "别让这个小巧版本……",
9  "text": "别让这个小巧版本……",
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 AI 网页爬虫

Thunderbit 针对 Facebook 企业主页自动建议的列，会生成一个干净、结构化的表格：

对于帖子和评论，输出会像这样：

结构化列、格式化电话、可直接使用的数据——不需要再做后处理。和 GitHub 工具吐出的原始 JSON 相比，差别一眼就能看出来。

Facebook 数据类型 × 最佳工具矩阵

到了 2026 年，没有任何单一工具能把 Facebook 上的所有东西都做好。

这张矩阵能让你直接跳到自己的场景，而不用整篇读完再猜答案。

你的团队适合哪种方案？

• 做线索开发的销售团队：先用 Thunderbit 的邮箱/电话提取器或 AI 爬虫。无需配置，马上出结果。
• 监控 Marketplace 的电商团队：用 Thunderbit 的定时爬虫，或者自建 Scrapy + 住宅代理方案（如果你有工程资源）。
• 搭建数据管道的开发者：GitHub 仓库（活跃 Fork）+ 住宅代理 + 维护预算。要接受持续投入。
• 归档群组内容的研究人员：只能走浏览器型工作流（Thunderbit 或带登录的 Selenium），并做合规审查。

最诚实的判断——也正是 ——是：没有一个单独方案能稳定搞定一切。你需要把具体的数据需求，匹配到正确的工具上。

逐步指南：如何从 GitHub 搭一个 Facebook 爬虫（在合适的时候）

如果你已经看完鲜活度审计，还是想走 GitHub 路线，那也行。下面是实际可行的路径——我会诚实说明哪里会坏。

第 1 步：选对仓库（用鲜活度审计表）

回到上面的审计表。挑一个与你目标页面类型最匹配、而且最不陈旧的仓库。在安装任何东西之前，先看 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 步：处理错误、限流和维护

• 加上重试逻辑和错误处理
• 预计要定期更新选择器或配置——这是一项持续维护，不是一次设置就完事
• 如果你发现自己花在维护爬虫上的时间，比花在使用数据上的时间还多，那就是该考虑无代码方案的信号了

关于 Facebook 爬取的法律与伦理考量

这一部分简短、直接，虽然不是文章重点，但忽略它是不负责任的。

Facebook 的 明确写着，用户“不得在未经我们事先许可的情况下，使用自动化方式访问或收集我们产品中的数据。”Meta 的 在 2026 年 2 月 3 日更新后，也明确说明了执行措施可以包括停用、移除 API 访问权限以及账号级处理。

这不是纸上谈兵。Meta 在 里写明了对未授权爬取的主动调查、停止侵权函和账号禁用。Meta 也曾对抓取公司提起过（例如 Voyager Labs 诉讼）。

最稳妥的理解方式是：

• Meta 的条款明确反对自动化抓取
• 使用有授权的 API，比未授权抓取更安全
• 数据公开可见，并不意味着可以无视隐私法义务（GDPR、CCPA 等）
• 如果规模较大，建议咨询法律顾问
• Thunderbit 设计上用于抓取公开可见数据，在使用云端抓取时不会绕过登录要求

核心结论：2026 年 Facebook 爬取到底什么能用

到了 2026 年，大多数 Facebook 爬虫 GitHub 仓库都已经失效或不可靠。这不是危言耸听，而是提交日期、Issue 队列和社区反馈反复显示出来的结果。

少数仍在活跃的 Fork 还能抓有限的公开页面数据，但它们需要持续维护、反检测配置，并且要接受“以后还是会坏”的现实预期。Graph API 有用，但范围很窄——它只覆盖在正确权限下的页面级元数据，不覆盖大多数人真正想要的广泛公开帖子或群组抓取。

对于需要 Facebook 数据、但又不想承担开发负担的业务用户来说，像 这样的无代码工具，是更可靠、维护成本更低的路径。AI 每次都会重新读取页面，所以 DOM 改动不会把你的工作流弄坏。你可以免费试用 ，并导出到 Sheets、Excel、Airtable 或 Notion。

实际建议很简单：先看鲜活度审计表。如果你不是开发者，先试无代码方案。如果你是开发者，只有在你有技术资源——以及足够耐心——去维护时，才值得投入 GitHub 方案。不管选哪条路，都要把具体数据需求匹配到正确工具上，而不是指望某个方案什么都能做。

如果你想进一步了解社交媒体数据抓取和相关工具，我们还有关于 、 和 的指南。你也可以在 观看实操演示。

常见问题

2026 年 GitHub 上还有能用的 Facebook 爬虫吗？

有，但选择很有限。最值得注意的是 kevinzg 原仓库的 Fork——当前状态请查看上面的鲜活度审计表。它可以部分抓取公开页面帖子和一些元数据，但它的 Issue 队列显示，mbasic 失效和空输出这类核心问题依然存在。大多数其他仓库要么已经放弃，要么完全坏掉了。

我可以不用写代码抓 Facebook 吗？

可以。像 以及免费的邮箱/电话提取器，都能让你在浏览器里点几下就提取 Facebook 数据，不需要 Python，也不需要 GitHub 环境。AI 每次都会重新读取页面，所以 Facebook 改版时你也不用维护选择器。

抓取 Facebook 合法吗？

Facebook 的 禁止未经许可的自动化数据收集。Meta 也会通过封号、停止侵权函和积极执行。合法性会因司法辖区和使用场景而异。尽量只处理公开可见的企业数据，避免个人主页，如果规模较大，请咨询法律顾问。

现在还能从 Facebook Graph API 拿到什么数据？

到了 2026 年， 已被高度限制。你仍然可以在具备正确权限（例如 ）的情况下，访问有限的页面级数据——比如 id、name、about、fan_count、emails、phone。大多数公开帖子数据、群组数据（）以及用户级数据，都已无法通过 API 获取。

Facebook 爬虫 GitHub 仓库多久会坏一次？

很频繁。Facebook 会持续更改其 DOM 结构、反机器人措施和内部 API——没有公开的固定节奏，但社区反馈显示，活跃爬虫往往每隔几周就会出现一次失效。moda20 Fork 因 mbasic 消失而出问题的 Issue 队列就是近期例子。如果你依赖 GitHub 仓库，就要为定期维护和输出校验预留预算。

了解更多