2026 年如何爬取推特（Twitter/X）数据：方法、工具、代码与成本

作者：Sorsa 编辑部 · 更新于 2026 年 7 月 31 日：对照 GitHub 和 PyPI 复核了开源库状态（twscrape、Scweet、Tweety 可用；snscrape、Twint、ntscraper 已失效；Twikit 上游版本当前不可用，靠社区分支维持），并在同月重新核对了 X 的按量付费 API 定价和 2026 年 1 月的服务条款。

审校：Keksich（Sorsa 创始人，X API 研究者）

核心要点： 2026 年爬取推特公开数据有三条路：驱动无头浏览器、拦截 X 内部的 GraphQL 响应；在已登录账号上跑仍在维护的开源库；把 URL 发给托管爬虫服务。三条路都需要住宅代理，多数还需要账号。X 每两到四周轮换一次访客令牌和 GraphQL 标识符，三条路都会跟着失效。只读数据 API 完全绕开这些，直接以 JSON 返回同样的数据。

搜索“推特爬虫”的人，多数其实并不想要爬虫。他们要的是数据。这是两个问题：数据才是目的，爬虫则是一份长期投入，包括住宅代理、会被封的一次性小号，以及每隔几周重新逆向一遍 X。

Sorsa API 是我们开发并运营的只读 Twitter/X 数据 API，所以本节请当作有立场的表述来读。取舍还是值得说清楚。爬虫费尽力气才抠出来的用户资料、推文、搜索结果和粉丝列表，一次 REST 调用就以干净的 JSON 返回。不用代理，不用登录，不用维护。批量接口每 1,000 条推文 $0.02 起、每 1,000 份用户资料 $0.01 起，最多可比官方 X API 便宜 50 倍，所有套餐统一 20 次/秒。没有申请，也没有审批队列，第一次调用约三分钟，头 100 次请求免费，无需绑卡。

如果你仍然想自己搭爬虫，为了掌控、为了学习，或者工作流真的需要，那么这份指南就是当下诚实的版本。下面会讲清楚：哪些数据真能拿到、可直接跑的 Python 代码、哪些工具还活着哪些已经死了、真实要花多少钱，以及法律红线在哪里。

目录

• 2026 年还能爬取推特吗？
• 哪些数据能爬，哪些爬不到
• 爬取推特合法吗？
• X.com 的底层如何运作
• 方法 1：无头浏览器爬取（附代码）
• 方法 2：开源 Python 库
• 方法 3：AI 辅助爬取
• 方法 4：托管抓取服务
• 如何找到要爬取的推文和主页 URL
• 爬取到底要花多少钱
• 方法 5：只读数据 API（不用爬虫）
• 该选哪种方法？
• 常见问题
• 我们如何研究并核实本指南

2026 年还能爬取推特吗？ {#can-you-still-scrape-twitter-in-2026}

能。2026 年不用官方 API 仍然可以爬取推特公开数据，但所有轻松的入口都已关闭。三处变化解释了难度的来源，本指南余下部分基本都在讲怎么绕开这三点。

第一，X 锁死了匿名访客访问，正是这一条终结了过去那套免费方案。第二，官方 API 改成按量付费，读取没有免费额度，“直接用官方 API”从第一次请求起就要花钱。第三，X 在每个公开页面上都收紧了机器人检测，就算爬虫本身跑得通，也得配住宅代理、控好节奏才活得下来。

回报依然真实。X 仍是全球最丰富的实时公开舆论来源之一。各团队还在持续爬取，用于品牌监测、舆情分析、竞品研究、获客、趋势发现和机器学习数据集。难度本身就是这类指南存在的理由：现在要解决的不是解析 HTML，而是先过反爬机制这一关。

哪些数据能爬，哪些爬不到 {#what-data-can-you-scrape-and-what-is-off-limits}

动手写代码之前，先弄清楚墙在哪里。没有登录会话时，你能拿到公开用户资料、单条推文及其可见回复，还有内嵌媒体的元数据。登录之后才可见的部分都够不着：受保护账号、私信、完整粉丝列表、完整搜索结果。除非你用真实账号爬取，那要承担封号风险。

匿名访问还有一些更软的限制。回复只能取到很浅的层级，访客视图的速率限制会在你翻到底之前切断长时间线。完整的历史推文存档需要大量滚动自动化，即便做到了也会撞上访客时间线上限。如果你要历史数据又不想爬取，数据 API 可以通过搜索检索到 2006 年以来的推文，还能拿到匿名爬虫根本碰不到的完整粉丝与关注列表。

本指南余下部分只覆盖公开、免登录的范围。这既是法律上最稳妥的一条线，也是不会让账号被封的那条。

爬取推特合法吗？ {#is-it-legal-to-scrape-twitter}

爬取推特公开数据处在真实的分裂状态：美国法院大体上保护这种行为，X 自己的服务条款则一概禁止。两件事同时成立，哪一件更要紧，取决于你面对的是刑法风险还是合同风险。

判例这一侧，天平偏向公开数据。2022 年第九巡回上诉法院确认，爬取公开可得的信息不违反《计算机欺诈与滥用法》，其中 hiQ 诉 LinkedIn 一系列判决被引用得最多。X 直接试过，也输了：联邦法院在 2024 年 5 月驳回了 X Corp. 诉 Bright Data 案，认定 X 针对该爬虫的主张大体上被优先法律排除；X 起诉反数字仇恨中心的案子也以第一修正案理由被驳回。访问真正公开的数据，不构成 CFAA 意义上的犯罪。

合同这一侧，X 的条款是更硬的约束。当前条款自 2026 年 1 月 15 日生效，禁止未经事先书面同意“以任何形式、出于任何目的”进行爬取或抓取。条款还附带违约金条款。任何人违反条款，在任意 24 小时内请求、查看或访问超过 100 万条帖子，即同意按每 100 万条帖子支付 $15,000，在欧盟、EFTA 和英国为同额欧元。2026 年的更新还把“内容”重新定义为涵盖 AI 提示词和输出，新增了针对越狱与提示注入的滥用条款，并设定了得州管辖地和集体诉讼弃权。违反条款属于合同问题，不是犯罪，但 X 可以封号、封 IP，并在你上了规模之后拿这一条说事。

三条规则能让公开爬取站得住脚：只取公开数据，绝不碰受保护账号、私信或任何登录后才可见的内容；不囤积，爬到的数据只保留到用例真正需要的期限；遵守速率限制，因为把对方服务器压垮才是法律风险真正落地的地方。欧盟读者还要多考虑一层：公开帖子里同样可能包含个人数据，只要你存储或处理，就适用 GDPR。以上是信息参考，不是法律意见；如果你的用例涉及敏感数据或高量爬取，请找律师谈。

X.com 的底层如何运作 {#how-xcom-works-under-the-hood}

理解 X 的架构，就能明白为什么每个爬虫最终都会失效。如果你爬过别的站点，X 的防御是另一个量级，原因是结构性的，不是偶然的。

X 是一个 React 单页应用。加载主页或推文 URL，服务器只返回几乎空白的 HTML 外壳。JavaScript 随后向后端申请访客令牌，再发起 GraphQL 查询去取真正的数据，最后由浏览器渲染。初始 HTML 里几乎没有有用内容，所以“拉一次页面再解析”的简单爬法什么也拿不到。这套设计给了 X 三个卡点。

访客令牌（guest token） 是每次 GraphQL 调用都必须带的临时凭据。令牌与你的 IP 绑定，几小时内过期，签发方式每隔几周就变一次。X 一改令牌签发逻辑，所有依赖旧方法的爬虫立刻停摆。这正是当年那批免费库的死因：全都建立在一条已经不存在的匿名访问路径上。

GraphQL 操作 ID（doc_id） 是嵌在 X 的 JavaScript 包里的标识符，用来告诉后端运行哪个操作。取用户资料、搜推文、加载时间线，各需要不同的 ID。X 每两到四周轮换一次，你要同时盯住八到十二个，而且没有任何文档，只能从压缩后的 JavaScript 里逆向，两周后再逆向一遍。浏览器驱动的爬虫能绕开这一层，因为页面会自己去请求当前有效的 doc_id。

速率限制与检测 是第三层。访客会话下，X 对每个 IP 大约限制每小时 300 次请求。数据中心 IP 一两次请求就会被标记。TLS 指纹识别能抓出网络栈模拟得不够真的无头浏览器，cookie 校验则会盯上可疑的会话模式。如果你用的账号被标记了，我们免费的限流检测几秒钟就能确认。

这些防御一直在变。下面这张表是 X 改了什么、什么时候改的事实记录，也解释了为什么一份只有十二个月历史的爬取指南，可能把你指向早已失效的工具。

结论是：X 不是一个稳定的目标。防御性变更大约每两到四周推一次，任何爬虫都等于订阅了一份持续跟进的义务。

方法 1：无头浏览器爬取（附代码） {#method-1-headless-browser-scraping-with-code}

最常见的自己动手方案，是自动化真实浏览器，加载 X 页面，再拦截携带数据的 GraphQL 响应。这套做法有效，是因为它跑的正是 X 期望的那套 JavaScript：页面自己去请求当前有效的 doc_id，数据也按对人类的方式渲染出来。你完全不用手动追踪操作 ID。

下面是用 Playwright 爬取单条推文的极简 Python 示例，思路是捕获后台的 TweetResultByRestId 调用：

from playwright.sync_api import sync_playwright
import json

def scrape_tweet(url: str) -> dict:
    xhr_calls = []

    def capture_response(response):
        if response.request.resource_type == "xhr":
            xhr_calls.append(response)

    with sync_playwright() as pw:
        browser = pw.chromium.launch(headless=True)
        page = browser.new_page()
        page.on("response", capture_response)
        page.goto(url)
        page.wait_for_selector("[data-testid='tweet']", timeout=15000)

        for xhr in xhr_calls:
            if "TweetResultByRestId" in xhr.url:
                data = xhr.json()
                return data["data"]["tweetResult"]["result"]

    return {}

tweet = scrape_tweet("https://x.com/elonmusk/status/1234567890")
print(json.dumps(tweet, indent=2))

脚本启动 Chromium，导航到一条推文，等页面渲染完，再从后台 XHR 调用里筛出携带推文数据的那一条。你拿到的是完整推文对象：正文、时间戳、互动计数、媒体 URL 和作者资料。推文字段嵌在 legacy 键下面，所以生产环境里通常只把需要的字段扁平化取出（正文、created_at、favorite_count、retweet_count、reply_count、view_count），而不是整棵树原样存下来。

同样的模式换个操作名就能用在别的页面上：用户资料是 UserByScreenName，用户时间线是 UserTweets，搜索是 SearchTimeline（搜索需要已登录会话）。爬用户资料时，等待条件从推文选择器换成 UserByScreenName，再从那条响应里读用户对象。

能拿到什么： 公开用户资料、单条推文、可见回复、引用推文和内嵌媒体。基本上公开界面能看到的都能拿。

不登录拿不到什么： 受保护账号、私信、完整粉丝列表，以及完整搜索结果和长时间线。登录后爬取能够到这些，代价是封号风险。

要让爬虫持续跑起来需要什么。 住宅代理没得商量，数据中心 IP 几乎瞬间被封；预算按每 GB $1 到 $3、每月 $50 到 $200 估（取决于用量）。你还需要指纹伪造、真实的视口尺寸、随机化的类人延迟，外加重试逻辑，用来兜住会话中途令牌过期，以及 doc_id 轮换时 GraphQL 接口返回空结果。这套代码今天能跑，在 X 下一次更新后的两到四周内就会失效，所以要按每月十到十五小时的维护量来打算。

方法 2：开源 Python 库 {#method-2-open-source-python-libraries}

与其从零搭建，不如直接用封装了 X 内部 API 的库。有些在活跃维护、目前可用；有几个被广泛推荐的其实早就死了；曾经的默认选项，现在上游版本也已经不可用。下面是诚实的图景，2026 年 7 月对照 GitHub 和 PyPI 重新核实过。

状态那一列才是这张表的意义，而且这一列一直在变。Twikit 长期是默认推荐：异步、文档完善、社区最大。但它在 PyPI 上的发行版被 X 2026 年的 webpack 和交易 ID 变更打断，用户已经转向仍在维护的分支，import 名依旧是 twikit。如果某篇教程还让你 pip install twikit 然后指望开箱即用，先看发布日期和未解决的 issue。就当下的只读数据采集来说，更稳的选择是 twscrape。

twscrape 就是为这件事造的。它用令牌或 cookie 认证，把会话存在本地数据库里，并自带多账号轮换，把请求分散到账号池上，比单账号方案更快冲过速率限制。需要知道的取舍有三点：仅异步、从设计上只读、没有内置断点续跑，所以跨天的大批量拉取要自己写检查点逻辑。命令行里一次搜索可以短到 twscrape search "from:xdevelopers lang:en" --limit=20，Python API 的写法与之对应。

坟场（别浪费时间）

如果一篇教程把上面任何一个当作当下的解决方案推荐，日期就是破绽。X 爬取的格局翻篇很快，所以我们才给可用工具表标上日期：上个季度还能跑的库，这个季度可能就没了。

每个可用库都有的那个坑

可用表里的每个库都需要一个已登录的 X 账号，这件事有后果。绝不要用个人账号，X 会封禁表现出自动化行为的账号，而且新爬虫账号的验证门槛也在提高。真要做体量，你需要好几个专用账号加一套轮换系统，住宅代理照样省不掉。就算是活跃维护的库，X 一推更新照样失效，那时你只能等维护者响应，或者等有人把它 fork 出来。

方法 3：AI 辅助爬取 {#method-3-ai-assisted-scraping}

AI 辅助爬取用一个语言模型替换掉脆弱的 CSS 选择器：模型读页面，按你用大白话描述的要求抽取内容。最知名的开源选项是 Python 库 ScrapeGraphAI。你在里面写一句提示词，比如“取每条推文的正文、作者和点赞数”，它自己推断结构；X 改版面时它重新适配，而不是在某个被改名的元素上直接崩掉。

这确实是对维护难题的一个真实回应，取舍也同样真实。模型仍然得先抵达页面，所以代理、账号和反爬绕过的要求一样都不少，LLM 一个也解决不了。每次抽取现在还要额外消耗 token，成本和延迟都上去了，输出也不如固定解析器那样确定。它适合做原型，适合版面经常变的页面；不适合便宜、高量、可重复的采集，那类场景要的是每条记录成本可预测。如果目标就是成本可预测加零维护，结构化数据 API 才是 AI 爬取想要达到的那个效果的更干净版本。

方法 4：托管抓取服务 {#method-4-managed-scraping-services}

托管服务替你运行整套抓取基础设施。你把查询或 URL 发过去，服务商返回结构化数据，代理轮换、令牌管理和反爬绕过都归服务商管。你会拿来对比的名字是 Bright Data、Apify 和 Scrapfly，Scweet 也在 Apify 上提供托管版本，带少量免费额度。好处是没有代码要维护，也没有代理要管。坏处是规模上的成本和供应商依赖：服务商的爬虫崩了，你只能等修复；计费口径又五花八门，按推文、按算力单元、按代理流量的每 GB 都有，光看标价很难比出真实的单条成本。

这是一个大到值得单独拆解的决定。各托管方案真实的每千条成本、可靠性和隐藏费用，见我们的 Twitter 爬虫工具对比。

如何找到要爬取的推文和主页 URL {#how-to-find-tweet-and-profile-urls-to-scrape}

上面每种方法都需要目标：你想拉取的具体推文和主页 URL。X 自己的搜索挡在登录墙后面，实际可行的变通方案是 Google，它索引了公开推文。用 site: 查询往往是不注册账号就能攒出一批目标 URL 的最快办法。

三种写法覆盖大部分需求。site:x.com inurl:status <关键词> 挖出与某个话题相关的单条推文。site:x.com <名称> 找到某个人或某个品牌的主页。再叠加 Google 的日期范围工具，就能筛出较新的帖子。唯一要说清楚的短板是：Google 索引比 X 实时内容滞后数小时到数天，突发内容它跟不上；但用来攒一批待爬的主页和帖子，效果很好。如果你要的是实时发现，而不是提前列好的固定目标，那正是按查询检索胜过爬取的地方，搜索 API 直接返回匹配的推文。

爬取到底要花多少钱 {#what-scraping-actually-costs}

多数教程报一个工具标价就打住了。爬取 X 的真实成本是工具，加住宅代理，加开发者时间，再加东西反复失效带来的经常性开销。下面是各条路线的完整图景。

决定结果的那一行是维护。开发者时间是这张单子上最贵的一项，而且它不会提前显形，要等到 X 第一次轮换 doc_id、你的数据管道在某个周五悄悄哑火时才浮出来。我们接触过的团队，为了让自建的 X 爬虫活着，经常每月投入十到十五小时，代理账单还要另算。给个量级感受：用浏览器自动化拉 1 万条推文，大约是 50 到 100 次请求，加几美元的住宅代理流量，这还没算工时。一旦把自己的时间计价，免费工具就不免费了。

方法 5：只读数据 API（不用爬虫） {#method-5-a-read-only-data-api-no-scraping}

读到这里，诚实的结论是：爬取 X 可行，但在时间、金钱和持续投入上代价不低，而且不少场景根本不需要爬。只读的 X 数据 API 通过普通 REST 接口返回同样的信息：用户资料、推文、搜索、粉丝、互动、社区数据，全部是干净的 JSON。请求头里带上 API 密钥就行，不用代理，不用访客令牌，不用 doc_id。

下面是用 Sorsa 的 API 做一次用户资料查询：

curl -H "ApiKey: YOUR_KEY" \
  "https://api.sorsa.io/v3/info?username=elonmusk"

这一行就返回完整的资料对象：ID、用户名、显示名、简介、粉丝数和关注数、推文数、认证状态、图片和注册时间。跟上面那 20 多行 Playwright 比一比，何况那个示例还没写代理设置、令牌管理和重试逻辑。

Sorsa 覆盖 40 个接口，横跨用户、推文、搜索、粉丝、验证、社区、列表和趋势，所有套餐统一 20 次/秒，没有按接口划分的窗口。批量接口每 1,000 条推文 $0.02 起、每 1,000 份用户资料 $0.01 起，其中 /info-batch（最多 100 份资料）和 /tweet-info-bulk（最多 100 条推文）这类调用各自只算一次请求。头 100 次请求免费，无需绑卡，你可以在 Playground 里无需代码测试任意接口，三分钟快速上手能让第一次调用直接跑通，不用审批。从官方 X API 迁过来的，迁移指南逐个接口对应了这次切换。

取舍是真实存在的，值得点明：API 是只读的，发帖、点赞、关注都做不了，而且你依赖的是服务商，不是自己的代码。对需要长期稳定运行的读密集型工作负载，这恰恰是想要的结果。

实战：一条不再崩的监测数据管道

一个中型金融科技分析团队来咨询时，正跑着自建的 Playwright 爬虫，对几百个金融和竞品账号做舆情实时监测。一直能用，直到用不了为止：X 每轮换一次 doc_id，数据管道就哑火，一名工程师要花掉一整天重新逆向新标识符、轮换代理。把开发工时和住宅代理算在一起，这份被他们当作例行支出的数据，真实月成本已经悄悄越过 $2,000。

他们把读取侧迁到数据 API，只保留真正属于自己的那部分继续建设。经常性的工程消耗归零，因为无论 X 平台侧改了什么，同样的 REST 调用每天都返回同样的 JSON，支出也降到“代理加工时”总额的零头。成本下降是从“带代理的按账号爬取”切到“按请求计费”的真实结果；维护量下降，则只是你不再运行爬虫之后自然发生的事。这个案例做了匿名处理，因为点名客户及其监测目标，可能把双方都暴露出去。

该选哪种方法？ {#which-method-should-you-use}

没有唯一赢家。选型取决于你的量级、预算，以及你能容忍多长时间的停摆。

想完全掌控抽取过程、把爬取当技能来学，或者工作流真的定制到没有工具覆盖，就用无头浏览器。想比自己动手更快上手，同时能接受封号风险和维护投入，就用开源库。想把基础设施外包出去，且可用性比成本更重要，就用托管爬虫。需要稳定的只读访问、承受不起每周失效，或者要在 X 数据之上交付产品，就用只读数据 API。任何写操作，发帖、私信、关注，都留给官方 X API，因为没有哪个爬虫或只读 API 能安全地做写入，广告和合规数据同样如此。

想看更广的服务商版图，见我们的 Twitter/X API 替代方案指南；想知道官方 API 现在要花多少钱，见 X API 价格详解；如果你还在关心免费额度是否还在，见 2026 年 Twitter API 还免费吗。

常见问题 {#faq}

2026 年还能爬取推特吗？

能，2026 年不用官方 API 仍然可以爬取推特公开数据，但轻松的路子已经没了。依赖匿名访问的免费库都已失效，访客浏览被限流，X 每两到四周轮换一次内部访客令牌和 GraphQL 标识符。当下可用的方式是：无头浏览器自动化、在已登录账号上运行仍在维护的开源库、托管爬虫，或者只读数据 API。

不登录能爬取推特吗？

能，但限制很重。不做认证时，无头浏览器爬取能拿到公开用户资料和单条推文，完整搜索、完整时间线、深层话题串和粉丝列表则受限或直接被拦。凡是能提供完整数据访问的开源库，都需要账号凭据或会话令牌，那才是解锁完整数据的东西。

2026 年爬取推特最好的工具是什么？

取决于你要做什么。高量只读数据采集，twscrape 是最可靠的在维护库，自带多账号轮换。Scweet 和 Tweety 同样可用。Twikit 的上游发行版被 X 2026 年的变更打断，目前靠社区分支运行，依赖之前先确认状态。若想要零维护、不碰代理也不担心封号的访问方式，像 Sorsa 这样的只读数据 API 通过 REST 接口返回同样的数据，每 1,000 条推文 $0.02 起，头 100 次请求免费。

能用 Python 爬取推特吗？

能，Python 是最常用的语言。你可以用 Playwright 驱动无头浏览器、捕获 X 的 GraphQL 响应，也可以直接用库：twscrape 适合多账号数据采集，Scweet 走 cookie 加 GraphQL 路线，Tweety 适合轻量拉取。Tweepy 也在，但它封装的是官方付费 API，不是爬取。如果 API 比爬虫更合适，我们的 Python 版 Twitter API 指南讲了 REST 路线怎么走。

爬取推特合法吗？

爬取真正公开的数据在美国通常是合法的，因为法院已经认定访问公开网络数据不违反《计算机欺诈与滥用法》。但这仍可能违反 X 的服务条款，那属于合同问题而非犯罪，后果是账号或 IP 被封。访问非公开数据则越过了 CFAA 的红线。在欧盟，只要公开帖子含有你存储或处理的个人数据，就适用 GDPR。以上是信息参考，不是法律意见。

官方 X API 还有免费额度吗？

没有。X 已停用免费额度，对新开发者改为按量付费。你需要预先购买额度，再按资源付费：每条帖子读取约 $0.005，每份用户资料约 $0.010，每条创建的帖子约 $0.015，标准账号每月 200 万条帖子读取的硬性上限。我们的配套指南 X API 是否免费介绍了当前的选项。

X 多久会让爬虫失效一次？

平均每两到四周。常见触发点是访客令牌签发方式变化、GraphQL 操作 ID 轮换，以及新增的反爬检测层。任何爬虫，无论自己动手还是基于库，都要定期更新才能保持可用，这份经常性维护是爬取方案最大的单项隐藏成本。

我们如何研究并核实本指南 {#how-we-verified-this-guide}

本指南建立在我们自己的工作之上：运营 X 数据 API，并对照 X 的线上接口做测试，再加上对每个工具当前状态的一次重新评审。这一轮里，我们直接在 GitHub 和 PyPI 上复核了开源库，确认哪些仍在维护。twscrape、Scweet 和 Tweety 在 2026 年活跃；snscrape、Twint 和 ntscraper 已经不在；Twikit 上游发行版不可用，靠社区分支运行。我们还读了 X 自 2026 年 1 月 15 日生效的服务条款，重点是其中关于爬取和违约金的措辞。判例部分的依据，是 EFF 对第九巡回 CFAA 裁决的摘要。我们自己 API 的定价来自 Sorsa 文档。X 的服务条款和官方 X API 定价于 2026 年 7 月重新核实，开源库拆解也在同月完成测试。库和平台条款变化很快，所以在依赖任何时效性内容之前，请对照原始来源再核对一遍。