在 GitHub 上搜索“facebook scraper”，会返回 475 个仓库。但只有 62 个 是在最近六个月内有更新的。
“能找到”和“真的能跑”之间的落差，就是 2026 年 GitHub 上 Facebook 抓取工具的真实写照。
我花了不少时间翻仓库的 issue 区、Reddit 上的吐槽，以及这些工具跑出来的真实结果。结论非常一致：大多数高星项目其实早就悄悄坏掉了，维护者也基本放弃，Facebook 的反爬机制还在不断升级。开发者和业务用户一次次搜到同样的结果、装上同样的仓库、然后遇到同样的空输出。本文就是一次 2026 年的现实核查——我们会客观盘点哪些仓库还值得你花时间，Facebook 又是怎么让它们失效的，以及什么时候你应该直接跳过 GitHub。
为什么大家会去 GitHub 找 Facebook Scraper
这个搜索背后的需求，其实和过去几年一直差不多，只是工具越来越不稳定：
- 开发潜客：提取企业主页的联系方式（邮箱、电话、地址），用于外联
- 电商监控：追踪 Marketplace 商品、价格和卖家信息，用于电商分析或套利
- 群组研究：归档帖子和评论，用于市场研究、OSINT 或社群管理
- 内容与帖子归档：保存公开主页的帖子、互动、图片和时间戳
- 活动聚合：抓取活动标题、日期、地点和主办方
GitHub 的吸引力很明显：代码可见、成本为零、理论上有社区维护，而且字段和流程都能自己掌控。
问题在于，星标和 Fork 数并不代表“现在还能用”。按 2026 年 4 月的数据来看，按精确短语“facebook scraper”星标最高的前 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 时代，当时脚本还能通过官方接口拉取页面/群组帖子，而这些接口如今已经不再广泛可用。
这些仓库通常会抓取的目标数据包括：帖子文本、时间戳、点赞/评论数、图片 URL、页面元数据（分类、电话、邮箱、粉丝数）、Marketplace 商品字段，以及群组或活动的元数据。
到了 2026 年，真正的取舍已经不是语言偏好，而是你能接受哪种失败方式。
2026 年 Facebook Scraper GitHub 新鲜度审计：哪些仓库真的还在工作？
我把 GitHub 上最热门、最常被推荐的 Facebook scraper 仓库，拿 2026 年的真实数据做了一次核查——不是看 README 怎么写，而是看提交时间、issue 队列和社区反馈。这一部分最关键。
完整新鲜度审计表
| 仓库 | 星标数 | 最后推送 | 未关闭 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（社区 Fork）
这是 kevinzg 最显眼的分支，增加了一些选项和面向 Marketplace 的辅助方法，比如 extract_listing（在它的 README 中有说明）。
但 issue 队列已经把问题说得很明白：
- “mbasic 不见了”
- “CLI 返回 ‘Couldn't get any posts.’”
- “https://mbasic.facebook.com 不再工作”
一旦 Facebook 简化版的 mbasic 前端改版或下线，整类 scraper 就会一起退化。
结论：这是最值得关注的分支，但在 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!!”
结论：已放弃。它高度依赖 Meta 早已大幅收紧的 API 权限模型。
其他值得一提的仓库
- 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 拥有主流平台里最激进的反爬系统之一。搞清楚这些具体防线，才是区分“能跑的 scraper”和“只会吐空结果的脚本”的关键。
Meta 自己在 2025 年 2 月的工程博客 中提到，他们有一个“Anti Scraping team”，会通过静态分析整个代码库识别抓取向量，发送停止侵权函、封禁账号，并依赖限流系统。这不是假设，而是明确的组织投入。
随机化 DOM 和 CSS 类名
Facebook 会故意随机化 HTML 元素 ID、class 名称以及页面结构。正如一位 r/webscraping 评论者所说：“没有任何普通 scraper 能在 Facebook 上稳定工作。HTML 在刷新之间都会变。”
会坏什么：上周还可用的 XPath 和 CSS 选择器，今天就可能抓不到任何内容。
应对方式：尽量使用基于文本或属性的选择器。基于 AI 的解析如果是读取页面内容，而不是死盯着固定选择器，通常更稳。要把选择器维护视为长期成本。
登录墙与会话管理
很多 Facebook 页面——比如个人主页、群组、部分 Marketplace 商品——都需要登录后才能看。无头浏览器要么被重定向，要么只拿到被阉割的 HTML。passivebot Marketplace scraper 的 issue 区里，“login to view the content”就是最常见的抱怨之一。
会坏什么：匿名请求拿不到内容，或者直接被跳走。
应对方式：使用真实浏览器会话的 session cookie，或者直接用能运行在已登录会话中的浏览器型抓取工具。轮换账号也可以做，但风险很高。
数字指纹识别
Meta 的工程博客提到，未授权的 scraper “通常会通过模仿用户正常使用产品的方式来隐藏自己”，这实际上等于承认：浏览器质量和行为质量是检测核心。社区在 3 月和 2026 年 4 月的讨论里，也持续建议使用 anti-detect 浏览器和一致的指纹。
会坏什么：标准的 Selenium 或 Puppeteer 配置很容易被识别。
应对方式：使用 undetected-chromedriver 或 anti-detect 浏览器配置。真实的会话质量和稳定指纹，比单纯伪装 user-agent 更重要。
基于 IP 的限流和封禁
Meta 的工程博客明确提到，限流是防御策略的一部分，包括限制关注者列表数量，以迫使对方发起更多请求，然后触发 速率控制。实际使用中，用户也反馈在以 10 秒间隔发帖到 10 个群组后就会被限流。
会坏什么：同一 IP 的批量请求很快就会被降速或封掉。数据中心代理 IP 往往一开始就会被拦。
应对方式：使用住宅代理轮换，而不是数据中心代理，并且把请求频率放低。
GraphQL Schema 变化
有些 scraper 会依赖 Facebook 内部的 GraphQL 接口，因为它返回的数据比原始 HTML 更结构化。但 Meta 并不会为这些内部 GraphQL 提供稳定性保证，所以这些查询常常会悄无声息地失效——返回空数据，而不是报错。
会坏什么：结构化提取会静默返回空结果。
应对方式：增加校验逻辑，监控 schema 接口，并固定到已知可用的查询版本。维护成本是躲不开的。
反爬防线总览
| 防线层级 | 它如何让 scraper 失效 | 实际可行的应对方式 | |---|---|---|---| | 页面结构频繁变化 / 选择器不稳定 | XPath 和 CSS 选择器返回空值或只抓到部分字段 | 优先用更稳的锚点，结合可见页面输出做校验，接受持续维护 | | 登录墙 | 未登录请求拿不到内容或被重定向 | 使用有效 session cookie 或浏览器会话工具 | | 指纹识别 | 普通自动化看起来太“机器” | 使用真实浏览器、一致的会话质量、anti-detect 措施 | | 限流 | 空输出、封禁、降速 | 降低频率、减少批量规模、使用住宅代理轮换 | | 内部查询变更 | 结构化提取静默变成空数据 | 增加校验，准备持续维护查询 |
当 GitHub 仓库失效时：该选择合规替代方案
一个坏掉的仓库，并不意味着你就该想办法绕过平台控制。先把业务问题说清楚：你需要的是页面级分析、广告透明度、公开联系人目录，还是商品目录？这些需求里，很多都可以通过官方 Meta 产品、授权 API，或者非 Meta 的公开来源来满足。
比如：只有在应用和用途都具备所需权限时，才使用 Graph API；只有符合条件时，才使用 Meta research 项目；广告信息则优先用 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 年，你会发现更多字段变成空值或缺失——这通常不是“小 bug”，而是被拦截的信号。输出通常是原始 JSON，还需要后处理。
示例输出：Facebook Graph API
Meta 当前的 Pages API 文档里说明了页面信息请求，例如 GET /<PAGE_ID>?fields=id,name,about,fan_count。Page reference 还包含 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 步：选对仓库（参考新鲜度审计）
回到上面的审计表，选择与你目标场景最接近、且最不老旧的仓库。在安装任何东西之前，先看 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 或配置 anti-fingerprinting
- 这一步不要省，标准 Selenium 或 Puppeteer 很快就会被标记
第 4 步：先跑一个小测试并校验输出
先从单个公开主页开始，不要一上来就抓大批量。仔细检查输出：
- 空字段或缺数据，通常说明你已经被 Facebook 的防线拦住了
- 把输出和浏览器里实际看到的页面内容做对照
- 一次成功的单页测试，比一份好看的 README 更重要
第 5 步：处理错误、限流和维护
- 加上重试逻辑和错误处理
- 预计要经常更新选择器或配置——这是一项持续维护，而不是“一次设置永久可用”
- 如果你发现自己花在维护 scraper 上的时间，比花在数据使用上的时间还多，那就是在提醒你该考虑无代码方案以外的路径了
Facebook 抓取的法律与伦理注意事项
平台条款、隐私规则、合同义务和数据保护法都可能适用。页面“公开可见”并不等于授权你自动化采集。请尽量最小化数据采集，记录目的和合法依据；如果是商业项目或大规模项目，务必咨询法律意见。
不要把浏览器扩展、已登录会话，或“公开”标签，理解为可以自动抓取 Meta 产品的许可。
核心结论：2026 年 Facebook 抓取真正可行的是什么
仓库活跃度、issue 队列和当前平台规则，比星标数或旧 README 更重要。如果业务问题针对的是你自己管理的资产，先从官方 Meta 工具和已批准 API 入手。对于市场研究、潜客研究和价格类问题，使用获准的非 Meta 来源通常更容易做文档化和治理。
常见问题
2026 年 GitHub 上还有能用的 Facebook scraper 吗？
有，但选择很有限。最值得注意的是 kevinzg 原仓库的 moda20/facebook-scraper 分支——当前状态请看上面的新鲜度审计表。它可以部分抓取公开主页帖子和一些元数据，但 issue 队列里明确显示 mbasic 和空输出等核心问题仍然存在。其他大多数仓库要么已经弃用，要么完全失效。
我能不能不写代码就抓 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 仓库多久会坏一次？
很频繁。Facebook 的 DOM 结构、反机器人机制和内部 API 都在持续变化——虽然没有公开固定周期，但社区反馈显示，活跃 scraper 往往每隔几周就会出问题。moda20 分支里关于 mbasic 消失的 issue 队列，就是一个很新的例子。如果你依赖 GitHub 仓库，务必要预留持续维护和输出校验的成本。
了解更多
