如何高效获取GitHub仓库的已关闭Issue数量？

一、提升Search查询的速率限制 #

Search API默认认证用户速率限制为30次/分钟，可通过以下方式优化效率：

• 使用个人访问令牌（PAT）认证：未认证状态下Search API仅10次/分钟速率，认证后直接提升至30次/分钟，是基础优化手段。
• 批量查询多仓库：在Search查询参数中一次性指定多个仓库，示例查询语句：

  q=repo:owner/repo1 repo:owner/repo2 is:issue is:closed
  

  结果会包含所有指定仓库的已关闭Issue，需根据每条Issue的repo字段拆分统计，以此减少请求次数、变相提升速率。
• 精准控制请求间隔：通过响应头X-RateLimit-Reset的时间戳计算速率重置时间，按30次/分钟的限制设置每2秒一次请求，避免触发限制导致阻塞。
• 采用GitHub App认证：企业级场景下，GitHub App的Search API速率限制最高可达100次/分钟，适配大规模仓库统计需求。

二、让Core查询仅过滤Issue对象 #

Core API的仓库Issue接口可通过参数精确过滤，排除合并请求（PR）：

• 指定type与state参数：调用/repos/{owner}/{repo}/issues接口时，添加type=issue和state=closed参数，示例请求：

  GET /repos/{owner}/{repo}/issues?state=closed&type=issue&per_page=100
  

  该参数会让接口仅返回已关闭的Issue，PR对应的type为pr会被自动排除。
• 分页遍历统计总数：Core API默认每页返回30条数据，可设置per_page=100减少分页次数。需遍历所有分页，累加每页Issue数量得到总数，可通过响应头Link字段判断是否存在下一页，或循环请求直至返回结果为空。

补充：若追求更高效率，可使用GitHub GraphQL API直接请求仓库已关闭Issue总数，无需分页遍历，速率限制为5000次/小时，示例查询：

query {
  repository(owner:"{owner}", name:"{repo}") {
    issues(states:CLOSED) {
      totalCount
    }
  }
}

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