Twitter API v2高频拉取千余账号最新推文的高效限流方案

接口基础能力确认 #

首先明确两个核心事实：

• 你提到的单用户时间线接口 GET /2/users/:id/tweets 确实不支持批量传入多个用户ID，单请求仅能查询单个账号的推文，单请求最多返回100条结果。使用App级Bearer Token鉴权时，该接口限流为15分钟900次请求，按20分钟的拉取窗口计算，单密钥最多只能发起1200次请求，直接遍历1500个账号必然触发429限流。
• 自建Twitter列表拉取推文不是唯一可行方案，但属于落地成本最低、稳定性最高的方案之一，以下是所有可落地的方案对比，按优先级排序。

可选方案对比 #

方案1：列表时间线接口（首选） #

这是免费/低付费层级下性价比最高的方案：

• 提前创建一个私有Twitter列表，将1500个目标账号全部加入列表即可（Twitter单列表最多支持添加5000个账号，完全覆盖你的规模需求）。
• 调用列表时间线接口 GET /2/lists/:id/tweets 拉取推文，该接口单请求最多返回100条列表内所有账号的公开发文，不需要为每个账号单独发起请求。
• 拉取时传入since_id参数，值为你上一次拉取到的最新推文ID，仅拉取两次拉取间隔内的增量内容即可，不需要全量翻取历史数据。正常场景下1500个账号20分钟内的增量内容，只需要十几次到几十次请求就能拉完，远低于该接口15分钟900次的App鉴权限流阈值，完全不会触发限流。
• 返回结果中自带每条推文的author_id字段，可直接和你本地维护的账号列表做映射，不需要额外调用用户信息接口做匹配。

方案2：最近搜索接口批量匹配（适合账号列表频繁变动场景） #

如果你不想维护Twitter列表，且账号有Elevated及以上的API访问权限，可以用最近搜索接口实现批量拉取：

• 调用 GET /2/tweets/search/recent 接口，查询规则拼接为(from:用户ID1 OR from:用户ID2 OR from:用户ID3 ...)的格式，单条规则可塞入数十个目标账号ID，单请求最多返回100条匹配结果。
• 同样传入since_id拉取增量，1500个账号只需要拆分为20-30次请求即可覆盖一轮，20分钟窗口内的请求量远低于该接口的限流阈值。
• 该方案的优势是不需要维护线上列表，账号列表增删时直接修改查询规则即可，适合监控名单变动频繁的场景。

方案3：多密钥轮询（兜底方案，不推荐长期使用） #

如果你既无法使用列表接口，也没有搜索接口权限，可以通过多API密钥轮询的方式兜底：

• 申请2个及以上独立的开发者应用密钥，为每个密钥配置独立的限流器，按单密钥15分钟最多900次请求的阈值做加权轮询，即可覆盖1500个账号每20分钟一轮的拉取需求。
• 该方案维护成本高，且存在违反开发者平台协议的风险，仅适合临时测试场景使用，不建议生产环境长期依赖。

Node.js落地核心注意事项 #

• 必须在客户端层做限流控制，推荐使用bottleneck库实现限流逻辑，每个密钥、每个接口单独配置限流规则，预留10%左右的请求冗余，不要卡着限流阈值发请求。
• 持久化存储每次拉取窗口内得到的最大tweet_id，下次拉取时作为since_id传入，仅拉取增量，可减少90%以上的无效请求。
• 本地维护账号ID和业务属性的映射表，不要额外调用用户信息接口补全数据，浪费请求额度。
• 如果使用列表方案，务必将列表设为私有，避免无关账号的内容混入结果，监控名单变动时直接调用列表成员管理接口增删账号即可。

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