Go 编译器 MergeLocals 测试为什么持续失败：局部变量合并与版本回移边界

CI 里看到 TestMergeLocalsIntegration 连续失败时，先别把它当成业务代码改坏了。这个测试检查的是 cmd/compile 在一份固定样例上能否产出足够的局部变量合并 trace；失败往往只说明编译器测试的观测条件变了。Go issue #80484 收集了这类一致失败，#81152 则是面向 Go 1.26 的回移跟踪项，两者都不能直接等同于“应用程序运行错误”。

最有用的判断顺序是：先确认是否成功调用 go tool compile，再看是否出现 stack layout for ABC，最后区分变量数量不足和合并簇不足；回移状态要单独以官方 issue 和对应版本发布记录为准。

TestMergeLocalsIntegration 先看哪条证据

官方测试文件先调用 testenv.MustHaveGoBuild，然后通过 go tool compile 编译 testdata/mergelocals/integration.go，并打开 mergelocalstrace=2,mergelocals=1。它并不锁定某个具体栈偏移，而是从 stack layout for ABC 后面的文本中收集变量和 frame offset，最后写入 varsAtFrameOffset 做分组统计。

go tool compile -p=p -c 1 -o p.a \
  -d=mergelocalstrace=2,mergelocals=1 \
  testdata/mergelocals/integration.go

所以第一刀应看编译命令本身的错误输出。若连对象文件都没有生成，优先排查工具链、构建能力或测试环境；若命令成功但没有目标段落，才进入 trace 格式和编译器输出分析。

为什么“8 个变量”与“3 个合并簇”不是一回事

源码将变量名放进 map，再统计相同 frame offset 的数量。expected trace output on 8 vars got 0 说明解析后一个变量都没有收齐；bad trace output line 说明输出行字段数量已经偏离测试约定；而 expected at least one clump of 3 表示变量收齐了，却没有至少一个超过两个成员的共享栈槽。

Go 1.26 回移该怎么判断

#80484 是持续失败的原始收集 issue，页面中的示例包含候选变量列表以及“期望 8 个变量、实际得到 0 个”的断言。#81152 由 Go 团队建立来跟踪把相关修复回移到 Go 1.26，并标注了 Go1.26.8 里程碑。这里的边界很关键：里程碑是发布管理信息，不等于每个已安装的 1.26.x 都已经包含修复。

排查时记录三项即可：go version 的完整输出、失败消息属于哪一层、对应版本的 Go 发布记录或 issue 是否已经明确给出修复版本。不要只因为换了 Go 版本后结果变化，就把差异写成业务层回归；这个测试本身依赖编译器内部 trace 和目标架构。

一份不误判的复查清单

先保存 CI 的完整 trace，再确认 stack layout for ABC 是否存在；接着统计解析到的变量数量和相同 frame offset 的最大簇。最后把结果与 #80484 的失败示例对照，并单独查看 #81152 的回移状态。若只是内部测试在某个工具链组合下失败，应用代码回滚通常没有帮助；更稳妥的处理是固定复现环境、等待或升级包含修复的版本，并为编译器测试保留原始输出。

常见问题

这个测试失败会导致 Go 程序运行错误吗？

不一定。它首先是编译器内部测试失败，只有进一步证明生成代码错误，才能讨论运行时影响。

为什么不能只看 Go 1.26.8 这个里程碑？

里程碑用于跟踪目标版本，实际是否修复仍要核对具体发布版本、提交和本地 go version。

能不能改测试，让它固定某个栈偏移？

不建议。官方测试刻意只检查变量合并簇，不锁定具体 frame offset，因为合法的贪心合并结果可能不止一种。