共计 1234 个字符，预计需要花费 4 分钟才能阅读完成。
阐明
不晓得从何时起，GitHub 限度了搜寻代码的后果，只能获取默认的前 100 条代码，且不反对排序筛选。
具体表现如下：
搜寻 aaa，共有22.5M 条数据，我每页展现 20 条数据，当查看到第 5 页时，无奈持续点击下一页，当通过批改参数查问第 6 页时，揭示我没有搜寻后果。
后翻了一下官网的文档，可见是官网限度了搜寻展现后果数量。
尝试绕过
以后阶段还是想尽可能多的获取到代码后果，毕竟从 GitHub 信息收集也次要依赖代码搜寻；但间接绕过 GitHub 搜寻策略是不事实的（能绕过我就提 hackerone 了），所以只能从测面想一些方法尽可能多的获取到后果，一个人的思路比拟局限，有其余徒弟有思路能够互相交换。
演示以搜寻 163 的 SMTP 账号密码为例，GitHub 间接搜
smtp.163.com password进去前 100 个后果没有 1 个能用的。
通过搜索引擎如 Google
site:github.com intext:"smtp.163.com" intext:password可见能搜寻一些可用的 SMTP 账号和明码。
通过欠缺搜寻的语法
GitHub 搜寻语法更新，能够应用正则表达式、布尔等高级搜寻语法进行条件限度。
163 默认邮箱生成的客户端密钥是 16 位，如JLLM**********GL，因而能够采纳减少搜寻规定的形式来放大搜寻范畴，如应用正则表达式
smtp.163.com AND /password = "[\w+]{16}"/因为局部用户可能改过密钥，所以也能够用如下语法：
smtp.163.com AND /password = "\w+"/ NOT /password = "(password|xxx|your_email_password|123456|X+| 明码 |authCode)"/通过 GitHub API
在 GitHub API 文档中，发现可通过 page 来管制查问的页数，如果咱们每页 1 条数据，那么第 101 页就是第 101 条数据，也就绕过了 web 的 100 条数据限度。具体演示如下：
# 认证
gh auth login
# 查问
gh api -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" '/search/code?q=smtp.163.com+password&per_page=1&page=101'可见能胜利获取到对应的仓库信息。
一行获取对应文件的内容
curl $(gh api -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" '/search/code?q=smtp.163.com+password&per_page=1&page=205' | jq -r .items[0].git_url) | jq -r .content | base64 -d问题点：
Github API 查问的后果数量和 GitHub 网页中查问的后果数量不统一，会少很多很多。