Go go test 怎样查看 stdversion 检查结果

我第一次遇到 stdversion，是在升级 Go 工具链后，原本能通过的 go test ./... 开始在测试执行前报标准库版本相关诊断。真正容易混淆的地方是：它不是说测试函数写错了，而是在提醒某个源文件使用了高于项目语言版本的标准库符号。

查看结果最直接的方式仍然是运行 go test，需要缩小范围时再使用 go test -vet=stdversion ./...。Go 1.27 的官方发布说明确认，go test 默认调用 stdversion vet 检查；检查依据包括 go.mod 中的 go 指令和文件上的 build tags。

先分清 go test 和 stdversion 各自负责什么

go test 做的是构建并运行测试，同时会对被测包及测试源文件运行一组高置信度的 vet 检查。stdversion 只负责其中一个很窄的兼容性问题：源文件调用的标准库符号是否超出了该文件所处 Go 版本。

所以看到诊断时，先不要把它理解成“当前安装的 Go 不能用这个 API”。更准确的判断是：当前工具链知道这个 API，但项目声明的语言版本或文件条件不允许把它当作所有目标环境都可用的接口。

从一条诊断中先看文件位置和符号名

诊断通常最有价值的部分不是最后的失败状态，而是包路径、文件名、行列位置和被指出的标准库符号。先定位到源文件，再确认这个文件是否被特定 build tag 纳入，最后才去看项目整体的 go.mod。

下面的示例故意把模块语言版本写得比代码所使用的标准库能力更旧。代码只用于说明诊断应该从哪里读，不代表本文在本机执行过这段示例。

package compatcheck

import "slices"

// HasReady 判断切片中是否存在 ready，示例关注标准库符号的版本边界。
func HasReady(values []string) bool {
	// slices.Contains 是需要结合项目 go 指令判断的标准库调用。
	return slices.Contains(values, "ready")
}

module example.com/compatcheck

go 1.20

如果使用 Go 1.27 工具链检查这个模块，重点不是猜测 slices.Contains 是否存在，而是读诊断中的三类信息：命中的文件位置、被判定过新的符号，以及项目声明的语言版本。这样才能判断问题属于代码兼容性，还是模块版本声明与实际支持范围不一致。

用 -vet=stdversion 单独查看检查结果

当完整的 go test ./... 同时报告多个 vet 问题时，我会先把检查器缩小到 stdversion，这样输出更容易和当前改动对应：

# 只运行 stdversion，便于把版本兼容性诊断从其他检查中分离出来
go test -vet=stdversion ./...

# 需要持续集成保存结构化测试输出时，再追加 json 模式
go test -vet=stdversion -json ./...

这里的 -vet=stdversion 是定位手段，不会改变源文件的语言版本，也不会自动把 go.mod 升级。若输出为空且命令退出成功，可以把它理解为：在当前包集合和当前文件条件下，没有发现 stdversion 诊断。

-json 主要改变测试事件的呈现方式，方便持续集成按包收集输出；它不是另一个版本判断器。阅读时仍要回到诊断中的文件位置和符号名。

按三个层次判断应该改哪里

第一层：确认 go.mod 的语言版本

先看 go.mod 的 go 指令。它表达的是模块允许使用的语言与标准库版本基线，不等同于机器上安装的 Go 工具链版本。若项目必须兼容较旧环境，就不能只因为本机工具链更新了而直接抬高这个值。

第二层：确认文件是否受 build tags 影响

同一个包可能因 build tags 选择不同源文件。stdversion 的判断落在具体文件上，因此应检查命中文件顶部的条件编译标记，以及目标构建环境是否真的会编译它。不要只看默认平台下的一份文件。

第三层：在“改代码”和“抬版本”之间做取舍

如果旧版本仍是产品承诺的一部分，应改用项目基线允许的标准库能力，或把新 API 放到明确隔离的文件中；如果项目已经不再支持旧版本，并且升级是有意的，才考虑调整 go.mod。这一步属于兼容性决策，不是为了让命令变绿而机械修改。

反向确认：修复后怎样读最终结果

完成调整后再次运行同一个范围的 go test -vet=stdversion ./...，重点看三件事：原文件位置不再出现同类诊断，其他 build tags 选择的文件没有新增诊断，完整的 go test ./... 仍能通过。

排查阶段可以临时使用 -vet=off 观察测试本身是否能运行，但这只是在隔离变量。它会关闭 go test 中的 vet 检查，不能作为兼容性问题的长期修复，也不能证明代码适配了项目声明的 Go 版本。

常见疑问

stdversion 是不是独立的测试框架？

不是。它是 vet 分析器，go test 可以在构建测试二进制前调用它。

为什么本机 Go 版本很新仍然会报错？

因为检查关注源文件所处的项目语言版本，不只看本机工具链版本。

空输出是否代表所有兼容性问题都解决了？

只能说明当前范围没有发现 stdversion 这一类诊断，不能替代其他测试、构建或运行环境检查。

把 go test 的完整结果和 go test -vet=stdversion ./... 的窄范围结果配合起来看，基本就能回答“哪里用了过新的标准库符号、项目实际支持哪个版本、应该改代码还是改版本基线”这三个问题。