从 2,500 次请求到 24 次：无需星标用户也能重建星标历史

GitHub 新增了一个用于获取仓库星标历史的聚合 API，同时大幅限制了旧版且包含用户身份信息的标星者端点。新端点一次请求最多可返回 30 周的每日星标数量，且不包含用户名或其他用户信息。根据 GitHub 2026 年 10 月 14 日的工程博客文章，重建 react/react 的星标历史目前约需 24 次请求，而此前的方法约需 2,511 次。

有哪些变化

最初的 GET /repos/{owner}/{repo}/stargazers 端点用于回答一个直接的问题：谁给仓库加过星标？它会返回一个分页的人员列表；当使用自定义媒体类型请求时，还会包含每个星标创建的时间。

这种设计带来了两个彼此独立的问题。由于可以批量获取身份信息，公开列表可能被抓取，用于垃圾信息和网络钓鱼活动。与此同时，即使调用方只收到最多 100 人的一页数据，每次请求也可能迫使数据库处理数千条当前星标记录。

因此，GitHub 将标星者列表和关注者列表的访问权限限制为仓库管理员和协作者。没有相应权限的调用方可能会收到空响应或 403 Forbidden 响应。这一变更还影响了那些利用旧响应重建星标历史图表的工具。在与维护者和工具开发者讨论后，GitHub 的产品工程团队与社区合作打造了一个专为此用途设计的聚合端点。

为何减少返回行数并未降低成本

星标模型保存的是仓库当前的标星者集合，而不是持久化的事件日志。有人取消星标时，相应记录会被删除。这让当前总数和标星者列表很容易获取，却使历史分析变得昂贵：工具必须获取单条记录并在本地汇总。

原端点还存在分页缺陷。每次请求都要统计所有当前星标，以确定总页数，尽管实际只返回一页。在限制访问权限的前一周，GitHub 报告称，有近 37,000 次此类计数查询因运行缓慢而被记录下来。它们平均耗时接近 3 秒，数据库保护机制终止了 1,000 多次查询，进而导致请求超时。

仅仅缩小响应规模无法解决底层工作负载。在常见的“先聚合、后分页”查询中，数据库会先找出所有匹配的星标，把这些行分组到时间桶中，再对这些时间桶排序。只有到这时才会应用 LIMIT 和 OFFSET。调用方最终可能只收到很小的结果集，但数据库此前已经扫描并处理了整个仓库的全部星标记录。

新端点如何减少数据库工作

最终上线的设计把时间过滤提前到了聚合之前。对于每次请求，GitHub 会将页码和 per_page 值转换为基于索引查询的 created_at 范围。它先筛选处于该范围内的星标记录，然后按天汇总匹配行。

单个响应最多可涵盖 30 周历史。
返回每日计数，不包含标星者身份。
页码越大，所返回的历史时段越早。
响应结构与现有的每周提交活动端点 GET /repos/{owner}/{repo}/stats/commit_activity 一致。

这一处理顺序是核心技术改进。每次请求只处理所请求的周，而不是仓库中的每个当前星标。以 react/react 仓库为例，该仓库约有 251,000 个星标；据报道，读取完整历史大约需要 24 次请求，在这些请求中每条星标记录总共大约只会被检查一次。相比之下，先聚合后分页的设计在同样的 24 次请求中会检查约 600 万行。

实际使用场景

维护者通常把星标历史当作衡量关注度的近似信号，而不是对单个用户的精确记录。这条曲线可用于比较版本发布、功能推出或公告前后的增长情况，也可以显示某项活动是否触达了项目现有受众之外的开发者。

Star History 等工具需要的是日期和汇总计数，而不是与它们关联的用户名。新端点直接满足这一更窄的需求。它移除了批量收集身份信息的途径，同时保留绘制整体趋势所需的信息，因此结果既更安全，服务成本也更低。

重要限制

该端点并不是每一次加星事件的完整记录。由于它以当前星标记录为基础，后来取消的星标不会出现在历史计数中。日历边界也会影响每周区间的划分，而星标异常密集的周仍可能导致昂贵的查询：时间范围限制了需要检查的历史跨度，但并未限制该范围内可能存在的星标数量。

正因如此，GitHub 将这些数据呈现为近似趋势，而不是全面的事件历史。接口约定明确涵盖日历边界、已移除星标和异常活跃时段的处理方式，而不是把这些边界情况留作未记录在案的实现细节。

更广泛的数据库影响

限制原始列表的访问还带来了可量化的成本节省。GitHub 报告称，变更后标星者请求减少了约 60%，计数查询所耗时间也减少了约 80%。此外，GitHub.com 上的仓库标星者页面已改为使用缓存的星标数量，而不是按需计数；此前每周数以百计的慢速查询降到了零。GitHub 此后还将类似改动应用到了其他与标星相关的端点。

更广泛的启示是，响应更小并不自动意味着查询成本更低。查询规划顺序很重要：一旦明确实际使用场景，系统就可以先筛选相关时间段，再进行聚合，只返回趋势分析所需的数据，并避免暴露该场景根本不需要的用户身份信息。

资料来源：From 2,500 requests to 24: Rebuilding star history without the stargazers（2026-10-14）。