待审队列指已经提交、正在等待评审或合入处理的变更集合。它把分散的评审请求按统一口径集中起来，让团队看清哪些变更在等待、卡在哪个环节、下一步由谁处理。本文围绕代码评审与合入管理解释这一概念的定义、边界与形成机制，不展开代码优化方法，也不核算评审等待时长等流动效率指标。
要点总览（TL;DR）
- 待审队列指已经提交、正在等待评审或合入处理的变更集合，回答“现在有哪些变更在等待处理、停在哪个环节”。
- 纳入范围是已提交且仍在评审或合入流程中的变更；代码优化方法、算法教程、评审等待时长等流动效率指标不在其内。
- 队列随提交、评审、修改、合入、关闭等动作动态增减，横跨评审与合入两个环节。
- 待审队列以变更为对象，区别于以人为对象的个人待办、以工作量为视角的积压，以及做时长统计的评审等待指标。
- 队列长度只是观察起点，变更质量由评审判断，流程效率需结合等待时长与评审轮次另行分析。
待审队列的直接定义
待审队列是代码评审与合入流程中的一个状态集合：所有已经提交、尚未完成评审或尚未完成合入的变更，都处于这个集合之中。它描述的是“当前有哪些变更在等待处理”，而不是“谁今天要做什么”或“团队一共欠了多少工作量”。
队列中的典型对象包括三类。评审请求是开发者发起的一次评审动作，通常附带变更说明、影响范围和期望的评审人；变更集是一次提交所包含的代码改动集合，可以是一个提交，也可以是多个提交的组合；合并请求则是把变更集从源分支合入目标分支的申请，它往往同时承载评审讨论与合入执行。三者可能在不同工具中名称不同、粒度不同，但共同点是都代表“已提交、待处理”的变更。
因此，待审队列回答的核心问题可以概括为：现在有哪些变更在等待评审或合入，它们分别处于哪个处理环节。这个定义有两个限定条件：变更必须已经提交，尚未提交的本地改动不在队列内；变更必须仍处于评审或合入流程中，已经合入或已关闭的变更已经出队。
待审队列包括什么、不包括什么
判断一个事项是否属于待审队列，最直接的依据是看它是否处于评审与合入流程中。处于流程中、尚未走完的变更纳入；流程之外的内容排除。这条依据比按名称判断更可靠，因为不同团队对“评审中”“待合入”的叫法并不统一。
| 范围 | 典型内容 | 判断依据 |
|---|---|---|
| 纳入 | 已提交、等待评审的变更集 | 已进入评审环节，尚未给出评审结论 |
| 纳入 | 评审已通过、等待合入的合并请求 | 评审环节完成，合入动作尚未执行 |
| 纳入 | 评审中被要求修改、修改后重新提交的变更 | 变更仍在流程内，等待下一轮处理 |
| 排除 | 代码优化方法、算法教程类内容 | 属于知识学习材料，不构成待处理的变更 |
| 排除 | 评审等待时长、评审周期等流动效率指标 | 属于对流程效率的度量分析，不是变更本身 |
| 排除 | 已合入、已关闭或已撤回的变更 | 已离开评审与合入流程 |
需要说明的是，排除某项内容只表示它不属于待审队列这个概念，并不表示它不重要。评审等待时长等指标用于分析流程是否顺畅，属于另一个分析视角；代码优化方法用于提升代码本身的质量，属于技术实践。把不同视角的内容混入待审队列，会让队列失去“待处理变更清单”的清晰含义。
待审队列是怎么形成的
待审队列不是预先建好的固定列表，而是随变更提交与处理动作动态形成的。它的基本机制可以按“进入—停留—离开”三个阶段理解。
进入阶段：开发者完成本地修改后提交变更并发起评审请求，变更随即进入待审状态。此时队列增加一项，等待评审人查看。若团队采用合并请求方式，提交合并请求的动作同样会把变更放入待审范围。
停留阶段：变更在队列中等待处理，可能经历多轮往复。评审人提出修改意见，变更回到开发者手中调整，调整后重新提交，再次进入等待评审的状态。这个阶段队列项数不变，但处理环节可能从“等待评审”转为“等待修改后再评审”。
离开阶段：当评审通过并完成合入，变更出队；当评审被驳回且变更被关闭或撤回，变更同样出队。评审通过但尚未合入的变更仍留在队列中，只是所处环节从评审转为合入。队列的增减完全由这些处理动作驱动，没有人为维护的静态名单。
从流程衔接看，待审队列横跨评审与合入两个环节：前半段等待评审结论，后半段等待合入执行。团队要判断“下一步由谁处理”，就需要区分变更当前停在这两个环节中的哪一个。在工具层面，评审请求与合并请求通常以工作项或评审记录的形式承载，状态字段反映其处于待评审、评审中、待合入等阶段；ONES 等研发管理平台可以把这类记录集中呈现，便于按状态查看当前等待处理的变更。具体字段与视图配置因团队实践而异，使用时应以实际配置为准。
待审队列与相关概念的区别
待审队列容易与几个相邻概念混用，区别主要在于对象范围和观察视角。
| 概念 | 对象范围 | 主要视角 | 回答的问题 |
|---|---|---|---|
| 待审队列 | 已提交、等待评审或合入的变更 | 流程状态 | 现在有哪些变更在等待处理 |
| 个人待办列表 | 某个人需要处理的事项，可包含评审、修改、回复评论等 | 个人任务 | 我今天要处理哪些事 |
| 积压 | 尚未完成的工作量，范围可覆盖需求、缺陷、变更等 | 工作量 | 还有多少事情没做完 |
| 评审等待指标 | 对评审等待时长、评审周期等的度量 | 流动效率与瓶颈分析 | 评审环节是否顺畅、瓶颈在哪里 |
与个人待办列表相比，待审队列以变更为对象，不区分处理人，同一条变更可能同时出现在多位评审人的待办中，但在队列里只计一次。与积压相比，积压强调未完成工作的总量，可以包含尚未进入评审的需求和缺陷；待审队列只覆盖已经提交、正在等待评审或合入的变更，范围更窄、状态更明确。与评审等待指标相比，后者是对队列流动情况的度量，需要采集时间数据并做统计，待审队列本身只是变更的集合，不包含时长核算。
理解这些区别的实际意义在于：看板上的队列长度适合回答“现在有什么在等”，个人待办适合安排“谁去处理”，积压适合评估“工作量是否过载”，等待指标适合分析“流程是否变慢”。四者配合使用，各自回答不同问题。
一个具体例子与常见误解
假设一个五人开发小组在周一上午提交了四个变更：变更 A 修改登录校验逻辑，已发起评审请求，等待两位评审人查看；变更 B 修复订单金额计算错误，评审已通过，等待合入主分支；变更 C 调整日志格式，评审人提出两处修改意见，开发者正在修改；变更 D 更新配置说明文档，刚提交评审请求。此时待审队列包含 A、B、C、D 四项，其中 A 和 D 处于等待评审环节，B 处于等待合入环节，C 处于等待修改后重新评审环节。
周二，变更 A 评审通过并完成合入，出队；变更 C 修改后重新提交，仍留在队列中等待复审；变更 D 被评审人驳回，开发者撤回后关闭，出队。此时队列剩 B 和 C 两项。这个例子说明，队列项数会随评审通过与关闭而减少，随新提交而增加，队列内容始终对应“当前仍在流程中的变更”。
围绕这个例子，有三条常见误解需要澄清。
误解一：把待审队列等同于所有未完成任务。未完成任务可能包括尚未提交代码的需求、待修复的缺陷、待编写的文档，这些都不在待审队列内。队列只收已经提交、正在等待评审或合入的变更。
误解二：把队列长度直接当成效率结论。队列长可能说明提交集中、评审人暂时繁忙，也可能只是当天提交量较大；队列短也可能是因为变更被快速关闭而非高质量完成。长度是观察起点，判断效率需要结合等待时长、评审轮次等数据另行分析。
误解三：认为进入队列即代表变更质量合格。进入队列只说明变更已提交并进入流程，评审正是为了检查质量。变更在队列中可能被要求修改甚至驳回，队列状态与质量结论是两件事。
把这三条误解放在一起看，待审队列的用法就清楚了：它是一份按流程状态组织的变更清单，用于识别当前等待处理的变更及其所处环节；质量判断交给评审，效率判断交给指标分析，工作量判断交给积压管理。各司其职，队列才能保持准确和可用。
常见问题
变更评审通过但还没合入，还算在待审队列里吗？
算。待审队列覆盖评审与合入两个环节，评审通过只说明变更从“等待评审”转为“等待合入”，它仍在流程内，尚未出队。只有完成合入，或者被驳回后关闭、撤回，变更才离开队列。团队查看队列时，需要区分变更当前停在哪个环节，才能判断下一步由谁处理。
同一条变更有多位评审人，队列里会重复计数吗？
通常按变更计一次。待审队列以变更为对象，不按处理人拆分；同一条变更可能同时出现在多位评审人的个人待办中，但在队列里只占一项。如果团队需要看“每个人手上有多少待评审”，那属于个人待办视角，与队列的统计口径不同，两者可以配合使用。
队列里积了很多变更，是不是说明评审效率低？
不能直接下这个结论。队列变长可能来自集中提交、评审人临时繁忙、变更拆分过细等多种原因；队列短也可能是变更被快速关闭而非高质量完成。要判断评审环节是否顺畅，需要采集等待时长、评审轮次等数据做流动效率分析，队列长度适合作为观察起点。
被要求修改后重新提交的变更，需要重新入队吗？
不需要重新入队，它一直在队列内。评审人提出修改意见后，变更从“等待评审”转为“等待修改后重新评审”，项数不变，环节变化。开发者修改并重新提交后，它再次进入等待评审状态。只有评审通过并合入，或被驳回后关闭、撤回，才真正出队。
团队想用工具管理待审队列，配置时要注意什么？
关键是让状态字段能区分“待评审”“评审中”“待合入”等环节，并保证评审请求或合并请求以统一记录形式集中呈现，避免同一变更在多处重复登记。具体字段与视图配置因团队实践而异，应以实际配置为准。ONES 等研发管理平台可以把这类记录集中呈现，便于按状态查看当前等待处理的变更。
