为何GitHub批量获取PR接口返回信息比单个PR接口少？

以下是几个核心的设计考量：

• 按需加载与职责划分：批量拉取PR列表的接口核心定位是快速提供概览级筛选能力，让调用者先圈定需要关注的PR范围，再通过单个详情接口获取完整数据。这种分层设计符合REST API的资源设计原则——列表接口做“快速浏览筛选”，详情接口做“深度信息查询”，避免给不需要完整数据的调用者返回冗余内容。

• 实时计算的性能成本：你提到的mergeable、rebaseable、mergeable_state这类字段并非静态存储值，而是需要实时计算的（比如检测分支冲突、验证合并可行性）。如果批量请求时给每个PR都实时计算这些状态，会大幅增加API服务器的负载——尤其是热门仓库，一次批量请求可能覆盖数十上百个PR，重复计算会拖慢响应速度，甚至触发限流机制。

• 版本兼容性的保守策略：GitHub API经过多年迭代，早期的批量接口是为基础列表需求设计的。后续新增的字段（比如maintainer_can_modify）可能仅在详情接口中实现，为了不破坏旧版调用者的兼容性，官方没有贸然把这些字段加到批量接口中，避免引发意外的解析错误。

• 累计资源消耗的优化：单请求1.4%的带宽节省看似不多，但对于GitHub这种高并发平台，每天数百万次的批量请求累加起来，节省的带宽和服务器资源是相当可观的。而且多数场景下，调用者确实只需要PR的标题、状态、作者等基础信息，变更行数、合并状态这类字段属于“按需获取”的内容。

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