GitHub将草稿拉取请求计入拉取请求数量限制

如果仓库已经设置了拉取请求数量限制，草稿拉取请求是否应该占用这个名额，会直接影响维护者能否控制队列规模。GitHub 在 2026 年 10 月 8 日的 Changelog 公告中说明：现在可以配置拉取请求限制，让草稿拉取请求也参与计数。此前草稿 PR 不计入用户的限制，因此可以在普通 PR 达到上限后继续创建草稿。

官方地址：https://github.blog/changelog/2026-10-08-draft-pull-requests-count-toward-pull-request-limits/

这次变化的关键是“草稿是否计入限制”成为可配置的控制范围，而不是 GitHub 宣布草稿 PR 默认全部改变状态。公告确认了能力和背景，没有进一步列出默认值、套餐差异或 API 细节。

为什么草稿 PR 也需要进入限制范围

草稿状态通常表示工作还没有准备好评审，但它仍然是一个真实存在的拉取请求对象。此前，数量限制只约束其他拉取请求时，用户可以不断创建草稿，直到仓库里出现大量尚未准备好的条目。对维护者来说，这会让队列管理变得困难，也可能带来更多通知和自动化任务。

公告到底新增了什么能力

公告的表述是：现在可以配置拉取请求限制，使其同时包括草稿拉取请求。这里有两个重点。第一，这是对“计数对象”范围的扩展，草稿不再天然处于限制之外。第二，公告说的是可以配置，并没有说明所有仓库会自动采用同一规则，所以阅读变更时不能把“支持纳入计数”理解成“所有现有规则已经自动切换”。

这项变化也没有把草稿 PR 变成普通 PR。草稿仍然可以表达“还没有准备好评审”的工作状态；变化只在于维护者可以让它参与数量上限的计算。至于组织使用何种上限、何时调整和如何通知贡献者，仍然属于仓库自己的协作策略。

团队启用前要先判断哪些事情

第一，检查当前限制服务的是个人贡献者、仓库维护流程还是更广泛的自动化治理，并确认草稿是否是团队日常拆分任务的主要方式。第二，评估把草稿纳入计数后，是否会让正常的阶段性工作过早触及上限。第三，把这项规则写进贡献指南或内部协作说明，让贡献者知道草稿也可能占用名额。

如果仓库主要受到垃圾或低质量贡献影响，把草稿纳入限制能够针对公告指出的绕过空间；如果团队大量使用草稿保存短期工作，也应该先盘点现有数量，再决定是否改变限制范围。GitHub 公告还邀请用户反馈这项设置的使用情况，遇到未说明的行为时，应以官方文档、仓库设置和官方反馈渠道为准，不要凭标题推断更多功能。

这次公告没有说明什么

当前公告没有列出默认是否开启、不同账户或套餐的差异、具体 API 字段、超限后的错误形式，也没有承诺其他草稿工作流会同步改变。文章只据此公告确认“草稿 PR 可以被纳入拉取请求数量限制”这一范围；实际落地时，仍要在目标仓库的现有配置中确认可见选项和行为。

常见问题

草稿 PR 以后一定会计入数量限制吗？

公告确认的是可以配置为计入，并没有说所有仓库自动采用相同设置。是否纳入，要看目标仓库当前的限制配置。

这次变化会把草稿 PR 自动转成普通 PR 吗？

不会。公告讨论的是数量限制的计数范围，不是草稿状态与评审状态之间的转换。

GitHub 为什么要扩大这个限制范围？

GitHub 给出的背景是减少低质量贡献造成的队列杂乱、通知和 CI 运行，并堵住草稿 PR 可以绕过既有数量限制的空间。