Twitter 粉丝 API：获取粉丝与关注（2026）

Q: API 调用里你该用 user_id 还是 username？

临时查询和探索用 username。任何跑不止一次的代码用 user_id。用户名在账号改名时会变；数字 ID 在账号存续期内稳定。对排定的作业，用 username-to-id 接口把用户名解析成一个 user_id 一次、存下来，从那以后传 user_id。

Q: 为什么提取的数量与资料的 followers_count 不符？

followers_count 值是 X 维护的一个实时计数器，所以可提取列表可能回来略小。被封账号、已停用用户，以及近期取关但尚未从计数器刷出的人都造成漂移。对大账号预期百分之几的差异。这是平台行为、不是你代码里的 bug，所以避免严格相等检查。

作者：Sorsa 编辑部

2026 年 7 月更新：新增了 100 次免费请求的起步选项，把 Sorsa 定价重新围绕每 1,000 份资料的费率来表述，并把官方 X API 成本刷新到当前的按资源费率卡。

要点： Twitter/X 粉丝 API 取回关注某用户的账号、以及该用户所关注的账号。官方 X API 暴露 GET /2/users/:id/followers 和 GET /2/users/:id/following，返回带完整资料元数据的分页用户对象。每个接口按返回的用户对象计费，所以一份粉丝列表的成本随账号大小扩展。

如果你曾试着在任何有意义的规模上从 X（前身 Twitter）拉一份粉丝列表，你就撞上过两堵墙之一。要么网页界面在加载几百份资料后悄然停下，要么你注册了官方 X API、却发现“取 10 万个粉丝”可能意味着一张四位数的账单。两者对人们真正拿粉丝数据要做的正事都行不通：竞争情报、销售线索生成、影响者发现、学术研究、活动核验。

这是面向开发者的走查：接口、认证模型、生产模式。如果你还没选定一个工具、想把 API 访问与浏览器扩展、自制爬虫和 X 原生数据导出权衡一下，我们关于提取 Twitter 粉丝的方法对比先覆盖那些取舍。本指南其余部分假设你已定下 API 路线。

Sorsa API，一个替代性的 Twitter/X API 提供方，用不同的成本结构处理与官方接口相同的数据。其 /followers 和 /follows 接口在单个 ApiKey 请求头之后每次请求返回最多 200 份完整用户资料，跑在固定的每秒 20 次请求上、无需应用审核，并按请求而非按用户对象计费。最后那个差别就是规模化粉丝数据的全部要害，下面各节会走通其中缘由，附官方接口、定价算术，以及可复制粘贴的 Python 和 JavaScript。

Twitter 粉丝 API 返回什么
2026 年官方 X API 取粉丝要花多少钱？
按资源计费 vs 按请求计费
Sorsa 粉丝和关注接口
取一页粉丝
翻遍一份完整粉丝列表
在规模上要紧的生产模式
为什么 /verified-followers 作为独立接口存在
会绊倒你的边缘情况
官方 X API 何时仍讲得通
常见问题
开始上手

Twitter 粉丝 API 返回什么 {#what-the-twitter-followers-api-returns}

Twitter/X 粉丝 API 返回一份分页的用户对象列表，每个粉丝一个，每个对象携带那个粉丝的完整资料、而非仅一个用户名。一次粉丝请求实际上是一次应用了关系过滤的批量资料查找。对每个粉丝，你通常拿到与直接资料查找相同的字段。

稳定的数字用户 ID 和当前用户名
显示名、简介、资料图 URL、横幅 URL
粉丝数、关注数、推文数
账号创建日期
位置字符串（自由填写、未经校验）
认证状态（Blue、Gold、Gray）
受保护/私密标志
简介里找到的 URL
置顶推文 ID

那份丰富度比看上去更要紧。用一次粉丝列表请求，你不只是在收集用户名；你是在拿到资格核定、分段或过滤受众所需的数据、无需第二轮资料查找。

官方 X API 把这拆成两个接口：

接口	返回
`GET /2/users/:id/followers`	关注指定用户的用户
`GET /2/users/:id/following`	指定用户所关注的用户

Sorsa 把同一对暴露为 GET /v3/followers 和 GET /v3/follows，外加第三个实用接口 GET /v3/verified-followers，只返回已认证账号（下面细说它为何单列）。

2026 年官方 X API 取粉丝要花多少钱？ {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

在 X API 按量付费模型下，粉丝和关注读取按返回的用户对象计费，对任何非你自己的账号按每资源 $0.010。一份 10 万个账号的粉丝列表就是 10 万个可计费资源、约 $1,000，不论你用了多少次请求去翻完。这是多数较老指南漏掉的细节，因为它们多数成文于 2026 年定价变更之前。

这个模型分两步到来。X 在 2026 年 2 月把按量付费设为新开发者的默认：没有免费额度、没有固定的 Basic 或 Pro 订阅，只是在开发者控制台里买的额度、按调用扣费。然后在 2026 年 4 月 20 日，X 把“自有读取”（对你自己账号数据的请求）砍到每资源 $0.001，而对任何其他账号的读取维持标准费率。据 X 的开发者社区，你按资源计费：一个有 1,000 粉丝的用户账号按每个 $0.010 合 $10、按返回的用户对象而非按请求计费。

这就是“自有读取”的玄机。取你自己开发者账号的粉丝列表现在很便宜。取一个竞品、一个影响者，或一个线索源的粉丝，是标准的非自有读取、按用户对象计费。X 对帖子读取施加的每月 200 万上限并不管辖粉丝读取，后者纯粹按资源计费。

账号大小	官方 X API（非自有读取，$0.010/资源）	Sorsa API（Pro）
1,000 粉丝	$10.00	~$0.01
10,000 粉丝	$100.00	~$0.10
100,000 粉丝	$1,000.00	~$1.00
1,000,000 粉丝	$10,000.00	~$10.00

披露：Sorsa API 是我们的产品。官方 API 数字用 X 发布的定价，其中非自有读取按返回资源计费、自有读取为每资源 $0.001，采用截至 2026 年 6 月现行的每资源 $0.010 用户读取费率；你的确切成本可能随超额处理和任何议定合同而变。我们建议在投入之前用你的真实工作负载测试任何提供方。

按资源计费 vs 按请求计费 {#per-resource-vs-per-request-billing}

决定粉丝数据成本的是按资源计费与按请求计费之间的差别、而非那个标称费率。官方 X API 把响应里每个用户对象都算作一个独立可计费资源，所以一次返回 1,000 个粉丝的请求，与 1,000 次单独查找花费相同。像 Sorsa 这样按请求计费的 API 把整个请求算作对月度配额的一个单位，不管里面回来多少用户。

对粉丝提取，这个差距很快复利，因为粉丝接口每次调用返回许多对象。在官方 API 上，一份 10 万粉丝的列表是 10 万个资源、每个 $0.010。在 Sorsa 上，同一份列表大约是 500 次请求（每次请求 200 份资料）计入月度配额，在 Pro 套餐上约 $1.00。数据形状相同；你付钱所对应的单位不同。

这就是一个第三方 Twitter API 市场之所以为粉丝数据存在的结构性原因。官方 API 在你只读自己账号时定价合理。对其他一切，按资源计费对你不利，而按请求模型是把成本压下来的杠杆。要看完整的跨提供方拆解，见我们的 Twitter API 定价指南。

Sorsa 粉丝和关注接口 {#the-sorsa-follower-and-following-endpoints}

Sorsa 粉丝接口是三个用单个 ApiKey 请求头认证的 GET 请求，没有 OAuth 流程、没有应用审核、也没有 bearer 令牌轮换。完整的粉丝和关注文档深入覆盖响应模式和分页行为。简短版：

GET /v3/followers 返回关注指定用户的账号。
GET /v3/follows 返回指定用户正在关注的账号。
GET /v3/verified-followers 返回与 /followers 相同的形状，但只含 Blue、Gold 和 Gray 已认证账号。

你把三个用户标识符之一作为查询参数传入，外加一个可选的分页游标：

参数	说明
`username`	不带 `@` 的用户名，例如 `stripe`
`user_id`	数字用户 ID，例如 `44196397`
`user_link`	完整资料 URL，例如 `https://x.com/stripe`
`next_cursor`	由前一次响应返回的可选分页游标

每页返回最多 200 个用户对象，属可得的每请求产出最高之列。官方 X API 把每次调用封顶在 1,000 个用户对象、却对其中每一个收费；Sorsa 每次请求返回 200 个、并把整批算作对你配额的一次请求。

取一页粉丝 {#fetching-one-page-of-followers}

对着 /followers 接口最小的可用调用是一次带用户名和你 API 密钥的 HTTP GET。一次请求、一次响应、无认证折腾。

cURL

bash

curl "https://api.sorsa.io/v3/followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

Python

python

import requests

resp = requests.get(
    "https://api.sorsa.io/v3/followers",
    headers={"ApiKey": "YOUR_API_KEY"},
    params={"username": "stripe"},
)
for user in resp.json().get("users", []):
    print(f"@{user['username']} - {user.get('description', '')[:80]}")

JavaScript（Node.js 或浏览器）

javascript

const resp = await fetch(
  "https://api.sorsa.io/v3/followers?username=stripe",
  { headers: { "ApiKey": "YOUR_API_KEY" } }
);
const { users } = await resp.json();
users.forEach((u) =>
  console.log(`@${u.username} - ${u.description?.slice(0, 80) ?? ""}`)
);

要改取一个用户所关注的账号，把 /followers 换成 /follows。参数形状和响应结构完全相同。如果你想在写任何代码之前就看到响应，近期粉丝工具在你浏览器里渲染任意公开账号最后 20 个粉丝，而 API Playground 让你不写一行就调用任意接口。

翻遍一份完整粉丝列表 {#paginating-through-a-complete-follower-list}

要取回第一页以外的粉丝列表，你用每次响应里返回的 next_cursor 值逐页前进：在下次请求里把游标传回，直到它返回为 null 或缺失。Sorsa 上一次请求返回最多 200 个用户，所以一份完整列表就是一个对那些页的循环。

下面是一个完整的、生产形状的 Python 循环，它处理分页、速率限制，以及一个硬性页数上限，这样一次失控的提取不会悄悄耗光你的配额：

python

import requests
import time

API_KEY = "YOUR_API_KEY"

def get_all_followers(username, max_pages=100):
    """取一个公开账号的完整粉丝列表。"""
    all_users = []
    cursor = None

    for page in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor

        resp = requests.get(
            "https://api.sorsa.io/v3/followers",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        )
        resp.raise_for_status()
        data = resp.json()

        users = data.get("users", [])
        all_users.extend(users)
        print(f"Page {page + 1}: {len(users)} followers (total: {len(all_users)})")

        cursor = data.get("next_cursor")
        if not cursor:
            print("Reached end of list.")
            break

        # Sorsa 的速率限制是每秒 20 次请求。两次调用间隔 50 毫秒是安全的。
        time.sleep(0.05)

    return all_users


followers = get_all_followers("stripe", max_pages=100)
print(f"\nTotal followers collected: {len(followers)}")

在每秒 20 次请求的速率限制下，这折合每秒挂钟时间大约 4,000 个粉丝。一个 10 万粉丝的账号约需 25 秒。一个一百万粉丝的账号约需四分钟。同样的游标模式适用于这个 API 上其他每个分页接口。

对一份关注列表，把 /followers 换成 /follows；其余一切保持相同。一个同时处理两者的统一辅助函数：

python

def get_user_graph(username, endpoint, max_pages=100):
    """endpoint 应为 'followers' 或 'follows'。"""
    all_users = []
    cursor = None
    for _ in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = requests.get(
            f"https://api.sorsa.io/v3/{endpoint}",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        ).json()
        all_users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.05)
    return all_users

在规模上要紧的生产模式 {#production-patterns-that-matter-at-scale}

一个整洁的循环在笔记本里能用。把粉丝提取跑进真实的数据管道（定时任务、多账号扫掠、下游富化），就会冒出另一组问题。这些是基础循环跑通后我们会去拿的模式。

干净地处理 429 响应

当你超过每秒 20 次请求的限制时，Sorsa 返回 429 Too Many Requests。修法很短：等一秒、重试。撞上限制没有惩罚，也没有令牌桶要走完。一个即插即用的包装：

python

import time
import requests

def get_with_retry(url, params, headers, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.get(url, params=params, headers=headers, timeout=30)
        if resp.status_code == 429:
            # 被限速。退避后重试。
            time.sleep(1.0 + attempt * 0.5)
            continue
        if resp.status_code >= 500:
            # 暂时性服务器错误。指数退避。
            time.sleep(2 ** attempt)
            continue
        resp.raise_for_status()
        return resp.json()
    raise RuntimeError(f"Failed after {max_retries} retries")

如果你的循环已经在两次调用间睡 50 毫秒，就极少会见到 429；它们多在你跨账号并行时才出现。速率限制文档描述了究竟什么计入配额。

长跑作业用 `user_id` 而非 `username`

用户名会变；数字 user_id 不会。如果你排定一个作业每周重新提取同一批账号的粉丝，把每个用户名解析成一个 user_id 一次并存下来。否则一个目标给自己改名，就会悄然弄坏数据管道，你的日志却说 "user not found"、没有明显起因。

python

def resolve_user_id(username):
    resp = requests.get(
        f"https://api.sorsa.io/v3/username-to-id/{username}",
        headers={"ApiKey": API_KEY},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["id"]

ID 转换接口覆盖全套：用户名转 ID、ID 转当前用户名，以及资料 URL 转 ID。存 ID，只在需要展示时才解析回用户名。

跨账号并行，而非在一个账号内并行

分页游标按设计是顺序的：你无法在没先取第 1 到 6 页时取第 7 页，因为每次响应把下一页的游标交给你。在单个账号的提取内部没有提速。

跨账号则不同。要从 20 个竞品拉粉丝，对着每秒 20 次请求的限制并发跑那 20 个提取。用异步 Python：

python

import asyncio
import aiohttp

async def fetch_page(session, url, params):
    async with session.get(url, params=params, headers={"ApiKey": API_KEY}) as r:
        return await r.json()

async def extract_one(session, username):
    users = []
    cursor = None
    while True:
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = await fetch_page(session, "https://api.sorsa.io/v3/followers", params)
        users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            return username, users
        await asyncio.sleep(0.05)

async def extract_many(usernames):
    async with aiohttp.ClientSession() as session:
        tasks = [extract_one(session, u) for u in usernames]
        return dict(await asyncio.gather(*tasks))

results = asyncio.run(extract_many(["stripe", "vercel", "supabase", "render"]))

把并发上限设为你的速率限制除以每请求延迟。在每秒 20 次请求、每请求约 150 毫秒下，三到四个并发提取就把上限打满。

处理响应数据

每个用户对象携带完整资料，所以多数下游处理不需要额外的 API 调用。关于形状有几点值得知道：

id 字段是字符串，而不是整数，即便看起来是数字。Twitter 用户 ID 超出某些语言原生处理的 64 位有符号整数范围，所以 API 把它们序列化为字符串。除非你的工具链安全处理 64 位值，否则不要转成 int。
created_at 字段是 ISO 8601（例如 2009-06-02T20:12:29Z），可直接解析：datetime.fromisoformat(created_at.replace("Z", "+00:00"))。不需要自定义格式字符串。
description（简介）可以含换行、表情符号和各种 unicode。在写进 CSV、或任何不干净处理 UTF-8 的数据管道之前，先做净化。
location 字段是一个用户自由填写的字符串、而非一个已校验的地理字段。要拿可靠的国家数据，受众地理工作流用 /about 接口拉取 X 附加到每个账号上的国家标签，按国家分析粉丝指南走一遍完整拆解。

要对受众做更深分析，我们关于提取 Twitter 粉丝的方法对比走一遍按简介关键词过滤做线索资格核定、以及找出同时关注多个竞品的账号。要把一份原始列表变成一张 CRM 就绪的表，见把 X 数据导出到 Google Sheets；要给同一份列表按虚假或不活跃账号打分，虚假粉丝审计指南覆盖了这一步。本文只停留在 API 机制上。

为什么 /verified-followers 作为独立接口存在 {#why-verified-followers-exists-as-a-separate-endpoint}

在客户端按认证过滤粉丝很平凡（u.get("verified") is True），所以一个专门的 /verified-followers 接口凭两个实际理由占得一席之地。第一，在有数百万粉丝、而已认证用户是一小撮少数的账号上，为把他们挑出来而走遍整个列表浪费请求和挂钟时间；这个接口只返回已认证子集、按与 /followers 相同的方式排序。第二，“高知名度受众”过滤在公关、新闻、投资者研究和影响者营销里够常见，值得一次调用。

bash

curl "https://api.sorsa.io/v3/verified-followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

响应和分页行为与 /followers 完全相同。完整模式见已认证粉丝 API 参考。

会绊倒你的边缘情况 {#edge-cases-that-will-trip-you-up}

即便在一个干净的 API 上，粉丝数据也有几个值得你在上线一条数据管道前就知道的怪癖。下面四个占了团队在生产里撞到的多数意外。

受保护账号返回一个错误。 如果目标把自己的推文设为私密（protected 标志为 true），其粉丝和关注列表对已批准粉丝之外的任何人都不可访问，接口返回一个错误，而不是一份部分结果。如果你在跨许多账号编写脚本，在提取之前用 /info 接口查资料的 protected 标志。

粉丝数和可提取列表不会精确相符。 一个资料的 followers_count 是 X 维护的一个实时计数器。你通过 API 走过的列表可能因为被封账号、已停用用户，以及近期取关但尚未从计数器刷出的账号而回来略小。对大账号预期百分之几的漂移，别对 followers_count 写严格相等检查。

资料数据是当前的、非历史的。 每个用户对象反映资料现在存在的样子、而非关注发生时的状态。如果某人在 2019 年关注了 Stripe、其后给自己改了名，你提取里的 username 是新用户名。数字 id 稳定；用户名不稳定。

排序大致是逆时间顺序。 /followers 和 /follows 都按 X 提供的顺序返回结果，一般是最新关注在前，所以头几页装的是最近获得的粉丝。X 没有正式承诺这个排序，所以别写死依赖这个顺序永远固定的逻辑，尽管实践中它一直稳定。

官方 X API 何时仍讲得通 {#when-the-official-x-api-still-makes-sense}

官方 X API 在两个具体情形下是对的选择：读你自己账号的数据，以及任何必须写入的工作流。读你自己的粉丝在 2026 年 4 月 20 日按 $0.001 自有读取费率变得便宜，所以对个人看板和账号管理工具，配 OAuth 用户上下文认证的官方 GET /2/users/:id/followers 是一个合理契合。写动作（发帖、点赞、关注）仅官方 API 有、也不是以读取为重的提供方所处理的。

对任何第三方账号（几乎每个商业应用都是这种情形），账就不一样了。按资源成本相比自有读取上升大约十倍，OAuth 2.0 给认证流程加了摩擦，而速率限制在 15 分钟窗口内强制执行、超出时返回 429、且多付钱也不放宽。对定价变更后正从官方 API 迁走的团队，Sorsa 的迁移文档覆盖逐接口的映射。

决策树很短：

只读你自己账号的数据？ 官方 X API 就行。便宜，且数据是权威的。
读任何其他账号的数据？ 一个替代性 Twitter/X API是更好的契合。成本差距大到无需细看。
需要发帖、点赞或关注？ 仅官方 X API。写动作超出像 Sorsa 这样只读提供方的范围。

实战中

我们为一家追踪金融科技 X 账号情感的量化基金重建了一个粉丝提取作业。他们需要约 50 个中层竞品账号的粉丝列表、每个平均 8 万粉丝、总共约四百万个用户对象。按官方 API 的非自有读取费率，那次一次性拉取定价接近 $40,000。同样的作业在一个按请求计费的第三方 API 上约合 $40 配额、一个下午跑完，数据形状一模一样。驱动因素是结构性的、而非一个折扣：官方 API 对返回的每个用户对象计费，按请求 API 则对调用计费、并在其中返回 200 份资料。对数以百万计的受众，抽样头 1 万到 2 万个粉丝（50 到 100 次请求）通常能代表近期受众、并避免为走遍完整长尾付费。

常见问题

什么是 Twitter 粉丝 API？

Twitter 粉丝 API 是那组以编程方式取回关注某 Twitter/X 用户的账号、以及在同一接口家族上取回该用户所关注账号的接口。官方版本是 GET /2/users/:id/followers 和 GET /2/users/:id/following。像 Sorsa 这样的第三方提供方通过单个 API 密钥和按请求计费、而非 OAuth 和按资源计费来暴露相同的数据。

你如何通过 API 获取一份 Twitter 关注列表？

要获取一份关注列表（一个用户所关注的账号，而不是关注他的账号），调用“关注中”接口，而不是粉丝那个。在官方 API 上那是 GET /2/users/:id/following；在 Sorsa 上是 GET /v3/follows，参数和每页 200 的分页与粉丝接口相同。关注列表通常比粉丝列表小，也往往更能说明问题，因为它展示了一个账号选择去追踪谁。

2026 年官方 X API 取粉丝数据要花多少钱？

在 2026 年 4 月 20 日更新之后，X 对“自有读取”（你自己的数据）按每资源 $0.001 收费，对任何其他账号的数据按标准非自有读取费率、每资源 $0.010 收费。账单按返回的用户对象、而非按请求计算。一份 10 万个账号的粉丝列表在非自有读取下约 $1,000。

按资源计费和按请求计费有什么区别？

按资源计费把响应里每个用户对象都算作一次单独收费，所以一次返回 1,000 个粉丝的官方 API 请求与 1,000 次单独查找花费相同。Sorsa 用的按请求计费，把整个请求算作对你月度配额的一个单位、不管回来多少用户。对粉丝列表（每次调用返回最多 200 个用户），这就是为 200 样东西付费、还是为一样东西付费的区别。

API 调用里你该用 user_id 还是 username？

临时查询和探索用 username。任何跑不止一次的代码用 user_id。用户名在账号改名时会变；数字 ID 在账号存续期内稳定。对排定的作业，用 username-to-id 接口把用户名解析成一个 user_id 一次、存下来，从那以后传 user_id。

你如何处理 429 速率限制响应？

睡一秒、重试。Sorsa 的每秒 20 次请求限制，撞上了也没有惩罚：你拿到一个 429，等待，下一次请求就成功。没有令牌桶、没有 15 分钟窗口、也没有逐接口子限制。一个捕获 429 和 5xx 响应、带短退避的轻量重试包装对生产就够了。

为什么提取的数量与资料的 followers_count 不符？

followers_count 值是 X 维护的一个实时计数器，所以可提取列表可能回来略小。被封账号、已停用用户，以及近期取关但尚未从计数器刷出的人都造成漂移。对大账号预期百分之几的差异。这是平台行为、不是你代码里的 bug，所以避免严格相等检查。

粉丝数据有多新？

用户对象反映资料在请求那一刻存在的样子，所以数量、简介、资料图和认证状态都是当前的。关注关系通常在 X 上发生后数秒到数分钟内被反映。要更接近流式的东西，实时监测模式覆盖如何在一个紧密的时间间隔上检测新粉丝和提及。

开始上手 {#getting-started}

要对着你自己账号或任意公开账号试这个：

在概览控制台上注册一个 API 密钥。每个新密钥都含 100 次免费请求：一次性、无需绑卡、永不过期、在全部 40 个接口上有效。在粉丝接口上那是在你付任何钱之前最多 2 万份资料。
用你的用户名作为 username 参数跑上面的 cURL 或 Python 示例。
要免代码预览，打开 API Playground、直接在浏览器里调用 /followers。
Sorsa 上的粉丝数据从每 1,000 份资料 $0.01 起，因为一次请求就按一次计费，返回最多 200 份完整资料。在定价页上为量做规划：Starter 从每 1,000 份资料 $0.02 起、Pro 和 Enterprise 从每 1,000 份资料 $0.01 起，每个套餐都跑在固定的每秒 20 次请求上。

完整代码、接口参考和分页模式住在粉丝和关注文档里。对于非 API 提取（浏览器扩展、自制爬虫、手动 X 数据导出），见本指南顶部链接的方法对比。要看第三方 Twitter 数据 API 市场在 2026 年整体上如何对比官方 X API，见我们的 Twitter API 替代方案拆解。

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

本指南是如何汇成的：接口、代码和模式来自我们打造并运营 Sorsa 的 Twitter/X API、以及对着实时公开账号跑粉丝提取的自身工作。官方 API 成本和模型对照 X 发布的开发者定价、以及 X 开发者资源里记录的速率限制行为核验。最后核验于 2026 年 7 月。

Twitter 粉丝 API：获取粉丝与关注（2026）

目录

Twitter 粉丝 API 返回什么 {#what-the-twitter-followers-api-returns}

2026 年官方 X API 取粉丝要花多少钱？ {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

按资源计费 vs 按请求计费 {#per-resource-vs-per-request-billing}

Sorsa 粉丝和关注接口 {#the-sorsa-follower-and-following-endpoints}

取一页粉丝 {#fetching-one-page-of-followers}

cURL

Python

JavaScript（Node.js 或浏览器）

翻遍一份完整粉丝列表 {#paginating-through-a-complete-follower-list}

在规模上要紧的生产模式 {#production-patterns-that-matter-at-scale}

干净地处理 429 响应

长跑作业用 `user_id` 而非 `username`

跨账号并行，而非在一个账号内并行

处理响应数据

为什么 /verified-followers 作为独立接口存在 {#why-verified-followers-exists-as-a-separate-endpoint}

会绊倒你的边缘情况 {#edge-cases-that-will-trip-you-up}

官方 X API 何时仍讲得通 {#when-the-official-x-api-still-makes-sense}

实战中

常见问题

什么是 Twitter 粉丝 API？

你如何通过 API 获取一份 Twitter 关注列表？

2026 年官方 X API 取粉丝数据要花多少钱？

按资源计费和按请求计费有什么区别？

API 调用里你该用 user_id 还是 username？

你如何处理 429 速率限制响应？

为什么提取的数量与资料的 followers_count 不符？

粉丝数据有多新？

开始上手 {#getting-started}

更多文章

如何在 X 上查看评论：查看回复（2026 指南）

Twitter 超出速率限制：起因与修复（2026）

如何按日期搜索 Twitter：操作符、工具与 API

目录

Twitter 粉丝 API 返回什么 {#what-the-twitter-followers-api-returns}

2026 年官方 X API 取粉丝要花多少钱？ {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

按资源计费 vs 按请求计费 {#per-resource-vs-per-request-billing}

Sorsa 粉丝和关注接口 {#the-sorsa-follower-and-following-endpoints}

取一页粉丝 {#fetching-one-page-of-followers}

cURL

Python

JavaScript（Node.js 或浏览器）

翻遍一份完整粉丝列表 {#paginating-through-a-complete-follower-list}

在规模上要紧的生产模式 {#production-patterns-that-matter-at-scale}

干净地处理 429 响应

长跑作业用 user_id 而非 username

跨账号并行，而非在一个账号内并行

处理响应数据

为什么 /verified-followers 作为独立接口存在 {#why-verified-followers-exists-as-a-separate-endpoint}

会绊倒你的边缘情况 {#edge-cases-that-will-trip-you-up}

官方 X API 何时仍讲得通 {#when-the-official-x-api-still-makes-sense}

实战中

常见问题

什么是 Twitter 粉丝 API？

你如何通过 API 获取一份 Twitter 关注列表？

2026 年官方 X API 取粉丝数据要花多少钱？

按资源计费和按请求计费有什么区别？

API 调用里你该用 user_id 还是 username？

你如何处理 429 速率限制响应？

为什么提取的数量与资料的 followers_count 不符？

粉丝数据有多新？

开始上手 {#getting-started}

更多文章

如何在 X 上查看评论：查看回复（2026 指南）

Twitter 超出速率限制：起因与修复（2026）

如何按日期搜索 Twitter：操作符、工具与 API

长跑作业用 `user_id` 而非 `username`