多 VM 并行开发，如何解决任务隔离、分支冲突与代码合并的一致性问题？**

VM 隔离与 Git 分支并行：单分支测试通过，合并后为什么仍然翻车

隔离解决的是执行，验证解决的是正确。

[读者] 正在用 VM + Git 分支做并行任务编排的平台工程师
[痛点] 每个分支单测全绿，合入主干后集成测试翻红
[现在读] 并行度已经提上去了，集成正确性成了新的天花板
[读完] 能落地任务 DAG、合并队列与集成门禁的组合方案

[旧方案] 一个任务一台 VM 一个分支，各自测绿就合
    |
    v
[新需求] 并行任务数上升，同一主干被多次并发切入
    |
    v
[冲突] 分支隔离了代码空间，隔离不了隐式依赖与基线漂移
    |
    v
[后果] 单分支绿合并后红，集成返工吃掉并行收益

我是老李，做研发效能方向的基础设施，主要给内部的多任务并行交付平台写调度与质量门禁。这个平台每天干的事很朴素：把一批需求任务分发给多个执行单元，每个单元一台独立 VM、一个专属 Git 分支、一份工作目录，跑完自己的测试就开 PR 合主干。

V1 阶段我们对「隔离」这件事有近乎信仰的信任。VM 之间不共享进程、不共享文件系统、不共享凭证，Git 分支之间不共享工作树，从资源视角看确实干干净净。于是我们默认：只要隔离做到位，任务之间就不会互相影响，各自测绿，合起来就该是绿的。

现实是，第一次主干集成测试翻红时，我们花了比写代码更长的时间去解释「为什么单分支全绿」。那一次之后我才真正接受一件事：隔离性回答的是「会不会互相干扰」，正确性回答的是「合起来对不对」，这是两个完全不同的问题。

那问题就来了：VM 隔离到了操作系统层，Git 分支隔离到了代码空间，为什么这两层叠起来，仍然挡不住合并后的回归失败？

是继续加机器把并行度推得更高，还是把预算挪去依赖治理、合并队列和集成门禁？

如果继续按「单分支测试通过即可合入」放行，等主干被污染之后，返工的代价由谁承担？

01、故事

现场是这样的：上游把一个季度的需求拆成一批任务丢进平台，每个任务带上目标仓库和一句自然语言描述。平台拉起一台 VM，在 VM 里 clone 仓库、按当时的主干 HEAD 切一个分支、执行改动、跑单测和静态检查，全绿就自动开 PR。合入主干之后，主干上还有一条集成流水线在跑全量回归。

任务是：让一批彼此不相干的需求真正同时往前跑，而不是排队等前一个人做完再开始下一个。V1 的设计完全服务于这个目标——一台 VM 一个分支，任务之间不共享任何可写状态，谁也别碰谁。

这套东西跑起来确实爽。单任务的端到端时间没变，但整体节奏明显快了，因为等待被并行填满了。我们的注意力全在「怎么让更多任务同时跑起来」，没人认真看过合并那一步。

转折点出现在一次很普通的合并。某个分支自己测得好好的，合进主干之后，主干的全量回归红了。第一反应是偶发，重跑，还是红。再一看失败用例，压根不在那个分支改过的那几行代码上——它踩的是另一个任务刚改过的共享契约文件，而那个契约变更，从来没出现在这个分支的视野里。

那一刻我才意识到，我们一直在优化「任务跑得多快」，却从来没有量化过「合并有多容易成功」。

一机一分支易
一主一真难
并行看单点
集成见全局

02、问题

旧方案失效得很有规律。把失败样本翻了一遍，能归成四类。

第一类，文件冲突。两个任务改同一个文件的重叠区域，PR 冲突标记满天飞，必须人工介入。这类问题最显眼，也最容易处理。

第二类，隐式依赖。任务 A 改了某个共享接口的签名，任务 B 写的代码基于旧签名。B 的分支基线还是旧的，所以 B 单测全绿；等 B 合入时，主干上已经有 A 的改动，B 的代码直接崩。两个任务在平台眼里毫无关系，因为依赖关系从来没人声明过。

第三类，分支基线过期。分支创建时的主干 SHA，和真正合并时的主干 HEAD，中间隔了好几个提交。分支上的全绿，验证的是那个旧世界。

第四类，测试环境不一致。不同 VM 的镜像版本、依赖缓存、环境变量有细微差别，测试结果之间根本没法互相印证，绿灯的含金量被稀释。

业务上的影响是很直接的：主干频繁变红，发布窗口被推迟，回滚次数上升，最要命的是工程师开始不信「绿」这个信号——看到绿，第一反应是「再跑一遍看看」。

技术上的表现反而是干净的：单分支 CI 全绿，主干集成流水线红。两边的信号完全矛盾，这个矛盾本身就是最贵的成本，因为它消耗的是判断力。

所以这一轮我们给自己定的完成标准是可验证的几条，而不是「感觉快」：

• 每次合并前，分支基线等于合并目标 HEAD，或者已经在合并队列里重新验证过；
• 同一批次内并行执行的任务，文件修改范围无交集；
• 合并后的集成测试，在锁定的镜像与依赖版本下运行；
• 主干上任一提交都能反查到任务 ID、Commit SHA、测试报告和审批记录。

单支全绿不是
合后翻红才是
标准先说清楚
才谈优化提速

03、原理

这一章只讲四个用得上的原理，它们后面会直接决定架构长什么样。

第一，隔离的边界在哪里。VM 隔离的是运行时资源：进程、文件系统、网络、凭证。Git 分支隔离的是代码空间：提交历史、工作树、索引。这两层加在一起，仍然不隔离「语义」——接口契约、数据库 schema、配置项、测试夹具、迁移顺序、feature flag 的开启时序。语义冲突不会在资源层暴露，也不会在代码空间层暴露，它只会在合并后的真实运行里暴露。

第二，基线漂移。代码正确性从来不是绝对的，而是「相对于基线」的。分支 A 在基线 X 上验证通过，只能证明「A 相对于 X 是正确的」。合并把基线换成了 Y，验证结论就自动失效了。所以合并后重新验证不是重复劳动，它是唯一一次在真实世界里的验证。

这里有个反直觉判断：合并后重跑一遍测试，看起来是浪费算力，其实是在补一个根本无法提前完成的工作。你在旧基线上跑一万遍，也跑不出新基线下的正确性。

第三，冲突有层次。最浅一层是文本冲突，Git 自己能标出来；往上一层是文件级冲突，同一文件被并发修改，可能自动合并成功但语义已经错位；再往上是语义冲突，改的是不同文件，但共享同一份契约；最深一层是时序冲突，迁移脚本、开关顺序、配置生效顺序，谁先谁后决定系统对不对。Git 只能解决第一层，而实践中出问题的往往在第三、第四层。

第四，二阶思维。并行带来的一阶收益是单任务等待时间下降，二阶成本是代码审查、冲突解决、回归验证全部变贵。当集成成本的增速超过并行收益的增速时，继续加机器只会让问题暴露得更早、更密集。

于是真正的优化目标必须换掉：不是单位时间跑完多少任务，而是单位时间内成功集成进主干的、且没有引起主干回归失败的有效变更数。前者是产能，后者才是吞吐。

再给一个反直觉判断：把分支数从 3 提到 10，有效变更吞吐量很可能不升反降。因为每多一个并行分支，其余分支的基线过期概率就上升一次，合并验证次数是组合级增长的。

隔离只保执行
不保结果正确
基线一旦漂移
验证便成空谈

04、架构

[输入] 任务请求（需求描述、目标仓库、基线 SHA）
    |
    v
[模块] 任务依赖 DAG 调度器 + 隔离执行器池 + 合并队列
    |
    v
[数据/状态] 分支、基线 SHA、文件修改范围、队列位置、权限凭证
    |
    v
[处理] 拓扑分层 → 文件范围去重 → 隔离执行 → 重基线 → 集成验证
    |
    v
[输出] 可追溯的主干提交（任务 ID + Commit SHA + 报告 + 审批）

四层的职责切分得很清楚。任务级负责「谁和谁能同时跑」：建立任务依赖 DAG，分析每个任务的文件修改范围，优先并行执行无依赖且范围不重叠的任务。执行级负责「跑得干净」：每个任务独立 VM、独立分支、独立工作目录、最小权限凭证，凭证按任务签发生命周期，任务结束即回收。集成级负责「合得对」：PR 评审、基线更新、冲突检测、合并队列、集成测试门禁。审计级负责「查得到」：把任务 ID、Commit SHA、测试报告、审批记录串成一条链。

边界必须说清楚。DAG 只能建模显式声明的依赖，加上从文件范围推断出的部分隐式依赖；纯运行时的契约冲突、跨仓库依赖，它管不了。合并队列只保证队列内部的顺序正确，队列之外的人绕过去直接推主干，它无能为力。集成测试只能覆盖它写过的用例，门禁的强度等于用例的强度。

收益也很明确：它把冲突的左移了。文件级冲突从「合并时的人工解冲突」前移到「调度时的批次划分」，隐式依赖从「主干变红」前移到「依赖声明缺失告警」，基线漂移从「合完才发现」前移到「入队即重验证」。

代价同样真实。调度器要维护每个任务的文件修改范围，任务启动前多一次分析开销；合并队列把原本瞬时的合入变成排队，单任务的感知延迟上升；集成门禁需要一套稳定的集成环境和一份可信的回归用例集，这两样都不是白来的。

适用条件：任务粒度中等偏细，仓库能切出相对独立的模块边界，主干要求持续可发布。如果团队本来就一天合一次、主干允许短期变红，这套东西的收益会明显缩水。

输入先定依赖
模块各守边界
状态随分支走
输出交门禁判

05、实战一次

先跑通一个最小但完整的 V1：一个任务分层调度 + 合并队列生成器。环境是 Python 3.11 及以上，只用标准库，不需要任何第三方依赖。

核心实现如下，文件名 dag_integrator.py：

from __future__ import annotations

import json
from collections import defaultdict, deque

# 每个任务：依赖列表 + 预计修改的文件集合
TASKS = {
    "T1": {"deps": [], "files": ["api/order.py", "api/schema.json"]},
    "T2": {"deps": [], "files": ["web/checkout.ts"]},
    "T3": {"deps": ["T1"], "files": ["api/pay.py", "api/schema.json"]},
    "T4": {"deps": [], "files": ["docs/api.md"]},
}


def topo(tasks):
    """拓扑排序，检测依赖环。"""
    indeg = {t: len(v["deps"]) for t, v in tasks.items()}
    children = defaultdict(list)
    for t, v in tasks.items():
        for d in v["deps"]:
            children[d].append(t)
    ready = deque(sorted(t for t, n in indeg.items() if n == 0))
    order = []
    while ready:
        cur = ready.popleft()
        order.append(cur)
        for nxt in sorted(children[cur]):
            indeg[nxt] -= 1
            if indeg[nxt] == 0:
                ready.append(nxt)
    if len(order) != len(tasks):
        raise ValueError("任务依赖存在环，无法调度")
    return order


def batches(tasks):
    """返回可并行批次：层内无依赖，且文件修改范围互斥。"""
    order = topo(tasks)
    done = set()
    result = []
    while len(done) < len(tasks):
        layer = [t for t in order
                 if t not in done and set(tasks[t]["deps"]) <= done]
        safe, touched = [], set()
        for t in sorted(layer):
            files = set(tasks[t]["files"])
            if files & touched:
                continue  # 文件范围冲突，降级到下一批
            safe.append(t)
            touched |= files
        for t in safe:
            done.add(t)
        result.append(safe)
    return result


def merge_queue(batch_list):
    """合并队列：每批作为一个原子单元，先重验证再落主干。"""
    queue = []
    for idx, b in enumerate(batch_list):
        if not b:
            continue
        queue.append({
            "position": idx,
            "tasks": b,
            "action": "rebase_to_head_then_revalidate_then_merge",
        })
    return queue


if __name__ == "__main__":
    bs = batches(TASKS)
    print("可并行批次:")
    print(json.dumps(bs, ensure_ascii=False, indent=2))
    print("合并队列:")
    print(json.dumps(merge_queue(bs), ensure_ascii=False, indent=2))

启动方式：

python3 dag_integrator.py

示例输出（未在当前环境实测，以下为预期结果）：

{
  "可并行批次": [["T1", "T2", "T4"], ["T3"]],
  "合并队列": [
    {"position": 0, "tasks": ["T1", "T2", "T4"], "action": "rebase_to_head_then_revalidate_then_merge"},
    {"position": 1, "tasks": ["T3"], "action": "rebase_to_head_then_revalidate_then_merge"}
  ]
}

验证三件事：一是 T1、T2、T4 依赖为空，进同一批；二是 T1 和 T3 都改 api/schema.json，范围重叠，所以 T3 即使依赖满足也降级到下一批；三是 T3 依赖 T1，天然排在 T1 之后，两重约束是叠加的。跑通之后 V1 的缺陷也摆出来了：它只知道文件范围，不知道语义漂移，也不知道合并那一刻主干已经走了多远。

最小闭环先跑
一次真实请求
证据留在线下
再谈规模铺开

06、排查

V1 上线之后依然会红，我们按诊断链一条一条走。

诊断链 A：合并后回归失败，失败用例不在本分支改动范围内

现象：分支 B 单测全绿，合入主干后主干全量回归红，失败用例落在另一个模块。

怀疑：第一反应是 B 的代码逻辑有问题。

检查：不看清逻辑，先看两个 SHA——分支 B 创建时的基线 SHA，和它真正合并时的主干 HEAD。再看主干上从基线到现在之间有哪些提交、改过哪些文件。

证据：分支 B 的基线是一个较早的 SHA，而合并时主干 HEAD 已经往前走了若干个提交，其中包含任务 A 对某个共享契约文件的修改；B 的失败用例全部落在消费这个契约的路径上。

根因：基线漂移叠加隐式依赖。B 的验证发生在旧世界，契约变更不在它的可见范围内。

修复：合并前强制 rebase 到最新主干，并在集成环境里重新验证；同时把「文件范围交集」推断出的隐式依赖写进 DAG，让这类任务不再同批并行。

诊断链 B：两个分支都没有冲突标记，合并后编译失败

现象：两个任务分别改了同一份 schema 文件的不同段落，Git 自动合并成功，没有任何冲突标记，但合并后构建失败。

怀疑：一开始怀疑是构建缓存污染，清缓存、换机器，问题依旧。

检查：把两个分支的 diff 逐段对比，重点看它们各自读写的字段语义，而不是看行号是否重叠。

证据：一方给某个字段加了新的枚举值，另一方写死了旧的枚举白名单校验，行级别完全没碰到，字段级已经矛盾。

根因：文件级冲突检测不等于语义冲突检测。Git 解决的是文本层，代码消费的是语义层，中间那层没人管。

修复：把共享契约文件列为「串行文件」，任何触及它的任务自动降级到同一批次内串行执行；同时在集成门禁里补契约兼容性用例。

错误尝试： 中间有一轮，我们把所有失败都归因到「测试环境不一致」，于是花力气把全部执行器的镜像、依赖版本、环境变量统一到同一份锁定清单。结果环境确实干净了，但那批跨模块的失败用例依旧在同一位置复现。为什么错？因为环境不一致是真实存在的问题，却不是这批失败的主因。我们犯的错是根据症状的显眼程度排序，而不是根据证据排序——镜像差异看得见，基线漂移看不见，但后者才是根因。这件事对反演思维是个提醒：先列出所有可能的失败因素，再用证据把它们排序，而不是用直觉。

怀疑要有证据
修复要指根因
错试也是收获
排序靠数据定

07、优化

V2 严格建立在第 06 章的两条证据之上，不做任何没有证据支撑的改动。

第一条根因：基线漂移 + 隐式依赖。修改方式是任务级和执行级各动一刀。任务级引入文件修改范围分析，把范围有交集的任务拆到不同批次；执行级在任务入合并队列前强制 rebase 到当前主干 HEAD。为什么这样做：既然验证结论相对于基线才成立，那就必须让验证和合并尽量贴近同一基线，中间的时间窗越短越好。新行为是：任务不再「测完就合」，而是「入队 → 重基线 → 重验证 → 再合」。验证方式是构造一个刻意制造基线漂移的场景，让两个有隐式依赖的任务并发执行，观察集成门禁能否在落主干之前拦住。

第二条根因：文件级冲突检测覆盖不了语义冲突。修改方式是给共享契约文件打上「串行」标记，并在集成门禁里补一层契约兼容性检查。为什么这样做：文本无冲突不代表语义无冲突，语义冲突无法靠 Git 发现，只能靠显式的契约测试发现。新行为是：触及契约文件的任务不再并行，而是排进同一批次串行执行，合入前必须过契约用例。验证方式是构造两个改同一文件不同段落、语义互斥的任务，确认它们不会被放进同一批次。

第三条，合并队列本身。原来的合并是「各自开 PR、各自合」，现在统一走队列：队列内部串行落主干，但队列允许把多个待合任务做一次预合并验证，验证通过才逐条落主干。为什么这样做：串行化解决的是顺序正确，预合并验证解决的是「这批一起合会不会互相打架」。新行为是：冲突在队列里暴露，而不是在主干上暴露。

第四条，审计链路。把任务 ID、Commit SHA、测试报告、审批记录四者关联起来，任取一个主干提交都能反查到是谁、基于哪个基线、跑了哪些用例、谁批的。为什么这样做：没有这条链，下一次回归失败时排查又得从零开始。

需要说明的是，上面全部是修改内容和验证方法，不含任何性能数字。真实效果必须在自己的仓库、自己的用例集、自己的并发规模下测出来才算数。我们关注的四个指标是：PR 冲突率、合并后回归失败率、平均集成时间、有效变更吞吐量。前三个衡量成本，最后一个衡量收益，四个一起看才能判断并行度该给到多少。

改在根因之上
验在集成之中
新行为要可测
旧问题要能复

08、演进

[同一输入]
    |
    +--[V1] 各分支独立验证后直接合入
    |        代价：主干回归失败、人工解冲突、信任损耗
    |
    +--[V2] 依赖分层 + 重基线 + 预合并验证 + 门禁后串行落主干
    |        代价：合并排队延迟、调度器复杂度、契约用例维护成本
    |
[Trade-off]
得到什么：把冲突与回归左移到合并之前，主干保持可用
失去什么：单任务从「跑完即合」变成「跑完排队等验证」
适用边界：任务数多、修改范围重叠概率高、主干要求持续可发布

从正确性看，V1 的正确性只在一个不断过期的基线上成立，V2 把验证挪到了真正要交付的那个环境里，正确性的可信度完全不同。

从稳定性看，V1 的主干状态随机波动，红是常态；V2 的主干被队列保护，但引入了新的失败点——队列本身。队列卡住，整条交付链就卡住，这是真实的新风险。

从复杂度看，V1 的调度器几乎是空的，V2 需要维护依赖 DAG、文件范围、串行文件清单、队列状态四份信息，任何一份失真都会让调度决策变错。复杂度不是涨了一点，是涨了一个量级。

从成本看，V2 多出了集成环境的算力开销、契约用例的维护成本、队列的等待延迟。这些成本是持续的，而 V1 省下的成本会以返工的形式在某个不确定的时刻一次性还回来。

从适用范围看，V2 适合主干要求持续可发布、并行任务数在两位数上下的场景；如果团队规模小、合并频率低，把 V1 加上一个「合并前 rebase」的小改动可能就够了，不必上整套队列。

遗留问题也很清楚：V2 仍然只覆盖到文件范围和显式契约，跨仓库依赖、运行时开关顺序、数据迁移顺序依然在射程之外。这些只能靠下一层的语义建模去补。

同一输入两解
取舍各有所付
快不等于有效
稳才是真吞吐

09、洞见

9.1 隔离与验证是两个正交的维度

所有失败都源于把这两个维度当成了一件事。VM 和分支提供的是「不互相干扰」的保证，而合并后的正确性需要的是「放在一起仍然成立」的保证。前者是执行域的属性，后者是集成域的属性，任何一个维度做到极致都替代不了另一个。工程上最危险的错觉，就是隔离做得很干净就误以为正确性会自动跟随。

9.2 反直觉判断：并行度不是吞吐量

直观上，把并发数从 3 提到 10，产出应该近乎线性增长。实际上，随着并发分支数上升，每个分支的基线过期概率都在上升，合并验证需要覆盖的组合数增长得更快。当集成成本的增长速度超过并行收益的速度时，有效变更吞吐量会掉头向下。真正的优化目标是单位时间内成功集成的有效变更数，这是一个带门禁的成功率指标，不是一个产能指标。

9.3 反直觉判断：合并前多跑一遍测试，是在省钱不是烧钱

很多人把「合并后重新验证」看作重复劳动，想尽办法跳过它。但从基线漂移的视角看，旧基线上的验证结论在新基线上不具备任何效力，那部分算力本来就没有产出有效结论。真正浪费的是在错误基线上重复验证一万遍，而不是在新基线上验证一次。越晚发现代价越高，这条规律在集成领域尤其残酷：分支上发现是改一行，主干上发现是回滚一次。

9.4 冲突有层次，只解决最浅那层等于没解决

文本冲突、文件级冲突、语义冲突、时序冲突，四层的处理成本依次上升，被发现的时间依次后移。Git 只负责第一层，而实践中真正让主干变红的往往是第三、第四层。所以冲突治理的抓手不在合并工具本身，而在把共享契约显式化、把顺序依赖显式化，让隐式的东西变成调度器能看见的东西。

9.5 可追溯性不是合规负担，是排查的折旧率

任务 ID、Commit SHA、测试报告、审批记录串成一条链之后，下一次回归失败的定位时间会显著下降。因为排查的本质是「在有限信息里排除可能性」，链路越完整，可排除的分支越多，收敛越快。反过来，没有链路时，每一次失败都要重新从零开始收集证据，成本不会随时间递减。

反直觉处见真
顺直觉处见坑
判断来自证据
洞见写进约束

10、系统落地

原来我们有的是什么：一个 VM 池、一套分支管理、一条单分支 CI。它能回答的问题是「这个任务自己跑起来对不对」，回答不了「它和别人一起跑起来对不对」。

本篇新增的是四件东西。任务级加了一层 DAG 调度与文件修改范围分析，让批次划分有依据；执行级保留了原有的 VM/分支/工作目录隔离，并把凭证收紧到任务级生命周期；集成级加了合并队列、重基线、冲突检测和集成门禁，让合入变成一个受控过程；审计级把任务 ID 与 Commit SHA 绑定，让「为什么这次合并会失败」变成一个可查询的问题。

现在能做什么：无依赖且范围不重叠的任务真正并行；有依赖或触及共享契约的任务按批次串行；合并批次先在集成环境里预验证，通过了才落主干；主干上任一提交都能反查到完整的证据链。

还缺什么：语义层的冲突检测依然缺位。文件范围是文件范围，接口契约兼容性、schema 演进兼容性、迁移脚本顺序，这些目前只能靠人工在评审里兜。另外合并队列的批量预合并调度还很粗糙，批大小的选择基本靠经验。

下一步的演进方向有两步。第一步，把「文件范围」升级为「契约范围」，接入契约测试与 schema 兼容性检查，让共享契约的变更能在调度阶段就暴露。第二步，让合并队列支持可配置的批量预合并，用预合并成功率去反馈调节批大小和并行度，把并行度从一个拍脑袋的常量变成一个被指标驱动的变量。

原来各跑各的
现在同过一门
还缺批量调度
下一步做预合

11、小结

Q1 → 因为隔离边界在资源与代码空间，不在语义与基线；验证结论只对它所在的那条基线成立
Q2 → 把预算挪向依赖治理、合并队列与集成门禁，有效变更吞吐量取决于成功集成数，不是任务启动数
Q3 → 由主干的使用者共同承担，所以门禁必须前置到合并之前，不能靠事后回滚兜底
状态 → 已具备任务分层调度、重基线合并队列、集成门禁与审计链路的最小可运行实现

这一轮最实在的收获，是把「并行」从一个追求最大化的目标，改成了一个需要被约束的变量。并行度本身没有价值，被成功集成的变更才有价值。

问题逐个作答
状态如实交付
能力落在门禁
边界写进文档

12、作业

12.1 理解题：为什么单分支测试全绿，不能证明合并后的代码正确？

参考答案：因为正确性是相对于基线的。单分支验证的是「相对于该分支创建时那个基线」的正确性，而合并会替换基线，并引入其他分支对共享契约、schema、配置、迁移顺序的改动。基线一变，验证结论的适用前提就没了，所以必须在真实的集成结果上重新验证，而不是把分支上的绿灯直接继承过来。

12.2 实战题：给定 5 个任务，其中 T1、T2、T4 无依赖，T3 依赖 T1，T5 依赖 T2 且与 T3 共用同一份 schema 文件，如何分批？

参考答案：先做拓扑排序，第一层是 T1、T2、T4。T4 与谁都不冲突，先入批；T1 和 T2 若文件范围无交集，可同批；T3 依赖 T1，必须等 T1 完成；T5 依赖 T2，但和 T3 共用 schema 文件，两者不能同批，需要在该层内按文件范围互斥挑一个入批，另一个降级到下一批。关键点是依赖约束和文件范围约束是叠加生效的，满足依赖不等于可以并行。

12.3 排障题：主干集成测试失败，但所有分支的单测都是绿的，你的排查顺序是什么？

参考答案：第一步比对分支基线 SHA 与合并目标 HEAD，确认验证基线是否已经漂移；第二步取参与合并的几个分支的 diff 交集，判断冲突处在哪一层——文本冲突、文件级冲突还是语义冲突；第三步在锁定的集成镜像与依赖版本下复现，排除环境差异干扰；第四步检查是否有未声明的隐式依赖或顺序依赖。全程以证据为排序依据，不要按症状的显眼程度排序。

12.4 架构判断题：为了提速，把合并队列改成「先合后验、失败再回滚」，是否可以接受？

参考答案：取决于主干是否要求持续可发布。如果主干是随时可发版的，这个方案不可接受，因为它把失败暴露点从合并前挪到了主干上，回滚成本和影响面都更大，还会让下游使用者失去对主干的信任。如果主干本身就是开发分支、允许短期变红、且有隔离的发布分支，那么在某些低并发场景下它可以作为一种简化方案，但必须配套快速回滚能力和明确的红时长阈值。判断的核心不是快慢，而是失败被暴露在哪个位置、由谁承担。

理解先于动手
实战再验一遍
排障照链走完
判断守住原则

13、思考

回到最初那个矛盾：我们明明把隔离做到了极致，为什么主干还是会红。

答案在最后变得很朴素——局部隔离保障的是独立执行的可行性，全局验证保障的才是系统的正确性。这两件事不能互相替代，也不该互相替代。VM 让每个任务跑得干净，Git 分支让每个任务的改动可追溯，而合并队列与集成门禁，负责回答那个没人愿意回答的问题：这些东西放在一起，到底对不对。

如果只能带走一个判断，我希望是这个：当你发现自己在疯狂提升并行度，同时又在为合并不停救火时，瓶颈早就不在执行侧了。此时再加多少台机器，都只是在更快地制造需要人工收拾的集成现场。把资源挪去依赖治理和合并验证，把衡量口径从「跑了多少任务」换成「成功集成多少变更」，系统的天花板才会真正抬起来。

局部隔离执行
全局验证正确
并行不是目的
集成才是终局