你可以使用 REST API 搜索你想要找到的特定项目。例如，你可以在存储库中找到用户或特定文件。你可以将它想象成在 Google 上执行搜索的方式。它的设计目的是帮助你找到你正在寻找的唯一结果（或你正在寻找的少数结果）。就像在 Google 上搜索一样，你有时希望看到几页搜索结果，以便找到最能满足你需求的项目。为了满足这一需求，GitHub REST API 为每次搜索提供多达 1,000 个结果。
你可以使用查询缩小搜索范围。要详细了解搜索查询语法，请参阅“用于搜索的 REST API 端点”。
除非另提供其他排序选项作为查询参数，否则结果按最佳匹配降序排列。将多个因素结合起来，将最相关的项目提升到结果列表的顶部。
REST API 对搜索有自定义速率限制。对于经过身份验证的请求，对于除“搜索代码”端点之外的所有搜索端点，每分钟最多可进行 30 次请求。“搜索代码”端点要求您进行身份验证，并限制您每分钟最多进行 10 次请求。对于未经身份验证的请求，速率限制允许您每分钟最多进行 10 次请求。
有关如何确定当前速率限制状态的信息，请参阅“速率限制”。
用于搜索的每个端点都使用 查询参数 在 GitHub 上执行搜索。有关包括端点和查询参数在内的示例，请参阅各个端点。
查询可以包含 GitHub 上支持的任何搜索限定符组合。搜索查询的格式为
SEARCH_KEYWORD_1 SEARCH_KEYWORD_N QUALIFIER_1 QUALIFIER_N
例如，如果您想搜索 defunkt 拥有的所有包含 README 文件中包含单词 GitHub 和 Octocat 的存储库，则可以使用以下查询和搜索存储库端点
GitHub Octocat in:readme user:defunkt
注意：务必使用您语言的首选 HTML 编码器来构建您的查询字符串。例如
const queryString = 'q=' + encodeURIComponent('GitHub Octocat in:readme user:defunkt');
有关可用限定符、其格式以及如何使用它们的示例的完整列表，请参阅“在 GitHub 上搜索”。有关如何使用运算符来匹配特定数量、日期或排除结果的信息，请参阅“了解搜索语法”。
您不能使用
- 长度超过 256 个字符（不包括运算符或限定符）的查询。
- 具有超过五个
AND、OR 或 NOT 运算符的查询。
这些搜索查询将返回“验证失败”错误消息。
为了让 REST API 对每个人都保持快速，我们限制查询将搜索的存储库数量。REST API 将找到多达 4,000 个与您的筛选器匹配的存储库，并从这些存储库返回结果。
为了让 REST API 对每个人都保持快速，我们限制任何单个查询可以运行的时间。对于超出时间限制的查询，API 将返回在超时之前已找到的匹配项，并且响应将把 incomplete_results 属性设置为 true。
达到超时并不一定意味着搜索结果不完整。可能已经找到了更多结果，但也可能没有。
您需要成功进行身份验证并能够访问搜索查询中的存储库，否则，您将看到带有“验证失败”消息的 422 不可处理的条目 错误。例如，如果您的查询包含 repo:、user: 或 org: 限定符，而这些限定符请求您在 GitHub 上登录时无法访问的资源，则您的搜索将失败。
当您的搜索查询请求多个资源时，响应将仅包含您有权访问的资源，并且不会提供列出未返回资源的错误消息。
例如，如果您的搜索查询搜索 octocat/test 和 codertocat/test 存储库，但您只能访问 octocat/test，则您的响应将显示 octocat/test 的搜索结果，而 codertocat/test 则没有任何内容。此行为模仿了 GitHub 上搜索的工作方式。
在 GitHub 上，您可以在搜索结果中使用代码片段和高亮显示提供的上下文。用于搜索的端点返回其他元数据，允许您在显示搜索结果时突出显示匹配的搜索词。
请求可以选择在响应中接收这些文本片段，并且每个片段都附有数字偏移量，标识每个匹配搜索词的确切位置。
要在搜索结果中获取此元数据，请在 Accept 标头中指定 text-match 媒体类型。
application/vnd.github.text-match+json
当您提供 text-match 媒体类型时，您将在 JSON 有效负载中收到一个名为 text_matches 的额外键，该键提供有关搜索词在文本中的位置以及包含搜索词的 property 的信息。在 text_matches 数组中，每个对象都包含以下属性
| 名称 | 说明 |
|---|
object_url | 包含与某个搜索词匹配的字符串属性的资源的 URL。 |
object_type | 在给定的 object_url 处存在的资源类型的名称。 |
property | 在 object_url 处存在的资源的属性的名称。该属性是一个与某个搜索词匹配的字符串。（在从 object_url 返回的 JSON 中，fragment 的完整内容将在具有此名称的属性中找到。） |
fragment | property 值的子集。这是与一个或多个搜索词匹配的文本片段。 |
matches | 存在于 fragment 中的一个或多个搜索词的数组。索引（即“偏移量”）相对于片段。（它们不是相对于 property 的完整内容。） |
使用 curl 命令和上述 示例问题搜索，我们的 API 请求将如下所示
curl -H 'Accept: application/vnd.github.text-match+json' \
'https://api.github.com/search/issues?q=windows+label:bug \
+language:python+state:open&sort=created&order=asc'
响应将为每个搜索结果包含一个 text_matches 数组。在下面的 JSON 中，text_matches 数组中有两个对象。
第一个文本匹配发生在问题的 body 属性中。我们看到问题正文中的一段文本片段。搜索词（windows）在该片段中出现两次，我们有每个出现的索引。
第二个文本匹配发生在问题的一个评论的 body 属性中。我们有该问题评论的 URL。当然，我们看到评论正文中的一段文本片段。搜索词（windows）在该片段中出现一次。
{
"text_matches": [
{
"object_url": "https://api.github.com/repositories/215335/issues/132",
"object_type": "Issue",
"property": "body",
"fragment": "comprehensive windows font I know of).\n\nIf we can find a commonly
distributed windows font that supports them then no problem (we can use html
font tags) but otherwise the '(21)' style is probably better.\n",
"matches": [
{
"text": "windows",
"indices": [
14,
21
]
},
{
"text": "windows",
"indices": [
78,
85
]
}
]
},
{
"object_url": "https://api.github.com/repositories/215335/issues/comments/25688",
"object_type": "IssueComment",
"property": "body",
"fragment": " right after that are a bit broken IMHO :). I suppose we could
have some hack that maxes out at whatever the font does...\n\nI'll check
what the state of play is on Windows.\n",
"matches": [
{
"text": "Windows",
"indices": [
163,
170
]
}
]
}
]
}