为何GitHub API初始请求后速率限制从5000骤降至30左右？

这是因为GitHub的Search API与普通Core API采用完全独立的速率限制配额体系，两者的额度不共享：

• 普通Core API（如获取用户详情、仓库信息等接口），授权后配额为5000次/小时
• Search API（包括你使用的search_users在内的所有搜索类接口），授权后配额仅为30次/分钟

你的代码里，client.rate_limit.remaining默认返回的是Core API的剩余额度，所以初始显示5000。但当你调用search_users后，Octokit会更新当前的速率限制上下文，此时rate_limit返回的其实是Search API的剩余额度——初始30次，调用几次后自然降到27、26这类数值，看起来像是骤降，本质是你混淆了两个独立的配额池。

验证方法 #

修改代码，单独打印Search API的剩余额度：

client = Octokit::Client.new(:access_token => TOKEN)

Users.find_each do |user|
  puts "Core API rate limit #{client.rate_limit.remaining}"
  puts "Search API rate limit #{client.rate_limit_search.remaining}"

  client.search_users(user.email)
  
  #...

  sleep(1)
end

运行后你会看到Core API的额度始终保持在5000左右，而Search API的额度从30开始逐步递减，这就能明确两者的区别。

解决建议 #

由于Search API的配额严格限制为30次/分钟，你需要调整请求频率：

• 将sleep(1)改为sleep(2)，确保每分钟请求不超过30次
• 若需要处理大量用户，可按分钟批量请求，每处理30次后等待1分钟再继续
• 避免在循环中频繁调用Search API（按邮箱搜索无法合并查询，只能控制频率）

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