GitHub Actions调整大查询计数：2500+表示超过阈值，分页上限另算

10-01 4阅读

2026 年 9 月 25 日，GitHub 宣布调整 Actions 工作流运行记录的查询计数。按工作流、事件、状态、分支或执行者筛选时，若匹配记录超过 2500 条，将报告“2500+”，而不再尝试给出精确总数。这个变化影响的是如何理解查询结果，不能只把显示文本改成一个整数继续使用。

配图为 AI 生成的概念示意图，非真实产品界面、设备照片或活动照片。

公告明确区分两个数字

官方说明，分页结果仍最多返回 1000 项。2500 是计数提示的阈值，1000 是该查询可返回的分页结果限制，二者不是同一种上限。GitHub 表示，大查询过去经常超时，可能把超时前找到的数量误当总量；此次调整旨在减少这种误导。

发布时该变化正在 github.com 与 GitHub Enterprise Cloud 推出。依赖大范围匹配结果的脚本应缩小过滤范围，例如加入日期区间。公告没有承诺一个查询可以通过不断翻页导出全部历史记录。

以下是假设例子：报表抓到 1000 条运行记录，页面提示 2500+，脚本却把二者之一当作整月总量。此时样本的失败率也可能被误标成全月失败率。修复的起点是给每个数量命名：匹配规模提示、已返回记录数、目标时间范围是否完整。

对用于审计或趋势比较的数据，还应保留查询条件与提取时间。当任务仍在持续产生新运行记录时，同一条件在不同时间得到的结果可能变化。若历史报表没有记录这些上下文，就不宜只凭两个总数判断系统发生了异常。

可以从较短的日期范围开始提取，并检查每段是否还触及结果限制。区间拆分必须说明首尾是否包含，合并时按稳定的运行记录标识去重；不能把相邻两天的查询结果直接相加，就假定没有重复或漏项。

最后随机抽查几条已知运行记录，确认它们在目标区间内恰好出现一次，再比较各段覆盖范围。若某段仍不完整，就继续细分或选用适合该任务的正式数据来源。本文的重点是保持统计口径诚实：无法确认完整的数据，应明确标为部分结果。

主要来源：GitHub：Changes to query results in Actions API and UI，公告日期 2026-09-25。本文于北京时间 2026 年 10 月 1 日核验，后续状态以官方更新为准。