关于主要速率限制
GitHub 限制您在特定时间段内可以发出的 REST API 请求数量。此限制有助于防止滥用和拒绝服务攻击，并确保 API 对所有用户可用。
某些端点（例如搜索端点）具有更严格的限制。有关这些端点的更多信息，请参阅“REST API 速率限制端点”。GraphQL API 也有单独的主要速率限制。有关更多信息，请参阅“GraphQL API 的速率限制和节点限制”。
通常，您可以根据您的身份验证方法计算 REST API 的主要速率限制，如下所述。
未经身份验证用户的首要速率限制
如果您只获取公共数据，则可以发出未经身份验证的请求。未经身份验证的请求与源 IP 地址相关联，而不是与发出请求的用户或应用程序相关联。
未经身份验证的请求的主要速率限制为每小时 60 个请求。
已验证用户的首要速率限制
您可以使用个人访问令牌发出 API 请求。此外，您可以授权 GitHub 应用程序或 OAuth 应用程序，然后它们可以代表您发出 API 请求。
所有这些请求都计入您每小时 5,000 个请求的个人速率限制。由您拥有的 GitHub 应用程序代表您发出的请求（该应用程序由 GitHub Enterprise Cloud 组织拥有）具有更高的速率限制，为每小时 15,000 个请求。同样，由您拥有的或经您批准的 OAuth 应用程序代表您发出的请求（该应用程序由 GitHub Enterprise Cloud 组织拥有）具有更高的速率限制，为每小时 15,000 个请求（如果您是 GitHub Enterprise Cloud 组织的成员）。
GitHub 应用程序安装的首要速率限制
使用安装访问令牌进行身份验证的 GitHub 应用程序使用安装的最低速率限制，为每小时 5,000 个请求。如果安装在 GitHub Enterprise Cloud 组织中，则安装的速率限制为每小时 15,000 个请求。
对于不在 GitHub Enterprise Cloud 组织中的安装，安装的速率限制将随着用户和仓库数量的增加而增加。拥有超过 20 个仓库的安装，每小时将额外获得 50 个请求，每个仓库 50 个请求。对于拥有超过 20 个用户的组织中的安装，每小时将额外获得 50 个请求，每个用户 50 个请求。速率限制不能超过每小时 12,500 个请求。
GitHub App 用户访问令牌（与安装访问令牌相反）的主要速率限制由经过身份验证用户的基本速率限制决定。此速率限制将与其他 GitHub App 或 OAuth 应用代表该用户发出的任何请求以及用户使用个人访问令牌发出的任何请求相结合。有关更多信息，请参阅“经过身份验证用户的基本速率限制”。
OAuth 应用的基本速率限制
由 OAuth 应用生成的 OAuth 访问令牌的基本速率限制由经过身份验证用户的基本速率限制决定。此速率限制将与其他 GitHub App 或 OAuth 应用代表该用户发出的任何请求以及用户使用个人访问令牌发出的任何请求相结合。有关更多信息，请参阅“经过身份验证用户的基本速率限制”。
OAuth 应用还可以使用其客户端 ID 和客户端密钥来获取公共数据。例如
curl -u YOUR_CLIENT_ID:YOUR_CLIENT_SECRET -I https://api.github.com/meta
对于这些请求，速率限制为每个 OAuth 应用每小时 5,000 个请求。如果该应用由 GitHub Enterprise Cloud 组织拥有，则速率限制为每小时 15,000 个请求。
注意：切勿在客户端代码或在用户设备上运行的代码中包含您的应用的客户端密钥。客户端密钥可用于为已授权您的应用的用户生成 OAuth 访问令牌，因此您应始终确保客户端密钥的安全。
GitHub Actions 中 GITHUB_TOKEN 的基本速率限制
您可以在 GitHub Actions 工作流程中使用内置的 GITHUB_TOKEN 来验证请求。有关更多信息，请参阅“自动令牌身份验证”。
GITHUB_TOKEN 的速率限制为每个存储库每小时 1,000 个请求。对于属于 GitHub Enterprise Cloud 帐户的资源的请求，限制为每个存储库每小时 15,000 个请求。
关于二级速率限制
除了主要速率限制之外，GitHub 还实施二级速率限制，以防止滥用并确保 API 可供所有用户使用。
如果您遇到以下情况，可能会遇到二级速率限制
- 发出过多并发请求。 允许的最大并发请求数为 100 个。此限制在 REST API 和 GraphQL API 中共享。
- 每分钟对单个端点发出过多请求。 REST API 端点允许的最大点数为每分钟 900 点，GraphQL API 端点允许的最大点数为每分钟 2,000 点。有关点数的更多信息，请参阅“计算二级速率限制的点数”。
- 每分钟发出过多请求。 允许的最大 CPU 时间为每 60 秒的实际时间 90 秒。GraphQL API 的最大 CPU 时间为 60 秒。您可以通过测量 API 请求的总响应时间来粗略估计 CPU 时间。
- 在短时间内在 GitHub 上创建过多内容。 通常，允许的最大内容生成请求数为每分钟 80 个，每小时 500 个。某些端点的内容创建限制更低。内容创建限制包括在 GitHub 网页界面以及通过 REST API 和 GraphQL API 执行的操作。
这些二级速率限制可能会在未经通知的情况下更改。您也可能因未公开的原因而遇到二级速率限制。
计算二级速率限制的点数
一些二级速率限制由请求的点数值决定。对于 GraphQL 请求，这些点数值与主要速率限制的点数值计算分开。
| 请求 | 积分 |
|---|---|
| 无变异的 GraphQL 请求 | 1 |
| 带有变异的 GraphQL 请求 | 5 |
大多数 REST API 的 GET、HEAD 和 OPTIONS 请求 | 1 |
大多数 REST API 的 POST、PATCH、PUT 或 DELETE 请求 | 5 |
一些 REST API 端点具有不同的积分成本，不会公开共享。
检查速率限制状态
您可以使用每个响应中发送的标头来确定主速率限制的当前状态。
| 标头名称 | 描述 |
|---|---|
x-ratelimit-limit | 您每小时可以发出的最大请求数 |
x-ratelimit-remaining | 当前速率限制窗口中剩余的请求数 |
x-ratelimit-used | 您在当前速率限制窗口中发出的请求数 |
x-ratelimit-reset | 当前速率限制窗口重置的时间，以 UTC 纪元秒为单位 |
x-ratelimit-resource | 请求针对的速率限制资源。有关不同资源的更多信息，请参阅“速率限制的 REST API 端点”。 |
您还可以调用 GET /rate_limit 端点来检查您的速率限制。调用此端点不会计入您的主要速率限制，但可能会计入您的次要速率限制。有关更多信息，请参阅“速率限制的 REST API 端点”。在可能的情况下，您应该使用速率限制响应标头，而不是调用 API 来检查您的速率限制。
没有办法检查您的次要速率限制的状态。
超过速率限制
如果您超过了主要速率限制，您将收到 403 或 429 响应，并且 x-ratelimit-remaining 标头将为 0。您应该在 x-ratelimit-reset 标头指定的时间之后再重试您的请求。
如果您超过了次要速率限制，您将收到 403 或 429 响应以及一条错误消息，指示您超过了次要速率限制。如果 retry-after 响应标头存在，您应该在经过这么多秒后才能重试您的请求。如果 x-ratelimit-remaining 标头为 0，您应该在 x-ratelimit-reset 标头指定的 UTC 纪元秒时间之后才能重试您的请求。否则，请等待至少一分钟后再重试。如果您的请求继续因次要速率限制而失败，请在重试之间等待指数增长的时长，并在特定次数的重试后抛出错误。
如果您在受到速率限制的情况下继续发出请求，可能会导致您的集成被禁用。
保持在速率限制内
您应该遵循最佳实践，以帮助您保持在速率限制内。有关更多信息，请参阅“使用 REST API 的最佳实践”。
获取更高的速率限制
如果您想要更高的主要速率限制，请考虑进行身份验证请求，而不是未经身份验证的请求。身份验证请求的速率限制明显高于未经身份验证的请求。
如果您在组织中使用个人访问令牌进行自动化，请考虑是否可以使用 GitHub App 代替。使用安装访问令牌的 GitHub App 的速率限制会随着存储库数量和组织用户数量的增加而增加。有关更多信息，请参阅“关于创建 GitHub App”。
如果您使用的是 GitHub App 或 OAuth App，请考虑升级到 GitHub Enterprise Cloud。对于使用 GitHub Enterprise Cloud 的组织，GitHub App 或 OAuth App 的速率限制更高。