使用twitter-api-v2获取特定用户全部粉丝时遭遇请求超限问题

问题根源 #

你的代码存在两个核心问题：

1. 分页器使用错误：开启asPaginator: true后，返回的是Paginator实例，无需手动维护next_token，且你错误地访问了more.data.data（正确路径应为more.data）。
2. 未处理速率限制：Twitter API对请求频率有严格限制，你的代码没有重试机制或延迟控制，连续请求直接触发了429错误。

具体解决方案 #

1. 正确使用官方分页器

twitter-api-v2的Paginator支持异步迭代，能自动处理分页逻辑，避免手动维护next_token的错误。修改代码如下：

async function getAllFollowers(userId) {
  const flist = [];
  // 每次请求拉取最大数量（1000条），减少请求次数
  const paginator = reader.v2.followers(userId, { max_results: 1000 });

  for await (const page of paginator) {
    flist.push(...page.data.map(item => item.username));
  }
  return flist;
}

2. 添加速率限制重试机制

Twitter API返回429错误时，响应头会携带Retry-After字段，指示需等待的秒数。你可以在创建API客户端时配置自动重试：

const { TwitterApi } = require('twitter-api-v2');

// 创建客户端时开启自动重试
const reader = new TwitterApi('你的Bearer Token或用户认证令牌', {
  retryConfig: {
    retries: 5, // 最多重试5次
    retryDelay: (count) => count * 1500, // 重试间隔递增
    retryOn: [429], // 仅对429错误重试
  },
});

3. 提升认证权限

你当前可能使用的是应用上下文认证（Bearer Token），该方式的速率限制为15分钟内15次请求。而**用户上下文认证（OAuth 1.0a/OAuth 2.0用户令牌）**的速率限制为15分钟内900次请求，能大幅提升拉取效率。如果你的机器人涉及用户操作，优先使用用户认证方式。

4. 添加请求延迟

在分页循环中添加短延迟，降低触发速率限制的概率：

for await (const page of paginator) {
  flist.push(...page.data.map(item => item.username));
  // 每次请求后等待1秒，避免高频请求
  await new Promise(resolve => setTimeout(resolve, 1000));
}

为什么机器人能实现该功能？ #

多数合规机器人采用了以下策略：

• 使用用户上下文认证，获得更高的速率限制配额；
• 实现完善的429错误重试逻辑，自动根据Retry-After等待；
• 批量请求时设置最大结果数，减少总请求次数；
• 部分大型机器人会使用多个合规的认证令牌（需符合Twitter开发者规则），分散请求压力。

内容的提问来源于stack exchange，提问作者JayJay