使用github3.py处理GitHub Search API二级速率限制的问题

首先明确：GitHub的二级速率限制不会体现在常规的rate_limit()接口返回结果中，你当前的check_rate_limit()只检查了resources.search.remaining这个常规请求配额，自然无法提前检测到二级限制，只有当请求被拦截时才会抛出ForbiddenError。

核心改进方案 #

1. 利用响应头的Retry-After字段
   触发二级限制时，GitHub的响应头会包含Retry-After字段，明确告知需要等待的秒数，比固定休眠2分钟更贴合实际限制要求。

2. 调整请求节奏
   github3.py的搜索结果生成器在迭代到分页末尾时会自动发起下一页请求，这个过程也会触发二级限制，因此需要在分页切换、关键词切换时增加合理间隔，而非仅在单条结果处理后休眠。

修改后的代码示例 #

import time
import logging
from github3.exceptions import ForbiddenError

for term in SEARCH_TERMS:
    # 检查常规搜索配额，避免提前耗尽
    self.check_rate_limit()
    result = gh.search_code(term)

    while True:
        try:
            item = next(result)
            # 处理逻辑...

            # 单条结果处理后的短间隔
            time.sleep(1)
        except ForbiddenError as e:
            # 提取官方指定的等待时长，无此字段时默认120秒
            retry_after = int(e.response.headers.get('Retry-After', 120))
            logging.error(f"触发二级速率限制，将等待{retry_after}秒")
            time.sleep(retry_after)
            # 重试当前迭代
            continue
        except StopIteration:
            # 分页结束后增加长间隔，避免连续发起新搜索
            time.sleep(10)
            break

额外注意事项 #

• 常规搜索配额（每小时请求数上限）和二级限制（短时间请求频率限制）是独立规则，需同时兼顾。
• 不要依赖固定休眠时长，优先使用Retry-After的值，GitHub会根据实时流量动态调整等待时间。
• 若脚本运行频率高，可将搜索请求分散到更长的时间窗口，比如处理完一个关键词后等待10-15秒再发起下一个搜索。

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