Merge Queue 适合 PR 合入频繁、主分支繁忙的团队。
它解决的问题是：每个 PR 单独看都通过 CI，但多个 PR 连续合入后，组合结果可能破坏主分支。
假设两个 PR 都基于同一个 main：
main: A
PR 1: A + B
PR 2: A + C
PR 1 和 PR 2 单独跑 CI 都通过。
但 PR 1 先合入后，PR 2 实际要合入的是：
A + B + C
这个组合结果没有被验证过，就可能把主分支弄坏。
启用 Merge Queue 前，先确认：
如果使用 GitHub Actions，关键工作流要响应 merge_group 事件：
on:
pull_request:
merge_group:
Merge Queue 适合在分支保护和必需检查稳定之后启用。CI 如果很慢，或者 flaky tests 很多，队列会把这些问题放大。
Shopify 的公开实践很有参考价值：当团队规模变大后，单个 PR 通过 CI 已经不够，还要验证排队后的组合结果，并且要把队列状态、失败原因、重试路径展示给开发者。Merge Queue 的核心价值，是把合入主分支前的组合风险提前暴露出来。
如果团队还没有稳定 CI、required checks、分支保护和 hotfix 路径，先补基础能力，再启用 Merge Queue。更多案例对照见 大厂工程实践决策图谱。