Go generate 为什么不会自动在 go test 前运行

项目里有一个很容易被误解的组合：源码写了 //go:generate，但执行 go test ./... 时，生成文件并没有更新。这个行为不是遗漏，而是 Go 工具链刻意保留的职责边界：go generate 是显式的代码生成入口，go test 负责加载当前已经存在的包文件、编译测试并运行测试。需要“测试前生成”时，应把两条命令写进脚本或 CI。

先理解两个命令的输入边界

官方 cmd/go 文档对 go generate 的描述很直接：它会读取已有文件中的生成指令，调用指令里的程序去创建或更新 Go 源文件，但不会自动运行在构建或测试之前。官方示例也是把 go generate、go build、go test 分开执行。

因此，go test 看到的是“此刻目录里的包”。如果 generated.go 尚不存在，可能得到未定义标识符；如果它存在但内容过期，测试甚至可能正常通过，却验证了旧代码。

生成指令只是契约，不是测试钩子

一个最小的生成入口通常放在普通的 Go 源文件中：

// 这条指令声明生成器和输出文件的关系
//go:generate go run ./cmd/gen

package widget

这里的注释告诉 go generate 要执行什么，不会改变 go test 的启动流程。官方文档还说明，指令必须从行首开始，文件名顺序和指令出现顺序会影响生成处理；生成器返回错误后，该包后面的生成工作会停止。

这也是为什么不建议把“测试命令会顺便生成”当作团队约定。新同事、编辑器任务、预提交检查和 CI 可能使用不同入口，隐式假设很快就会失效。

把生成步骤接到测试前

如果项目确实要求每次测试前更新生成文件，把依赖关系写出来即可。下面这个脚本没有改变 Go 命令的语义，只是把工程流程固定下来：

#!/usr/bin/env sh
set -eu

# 先根据源码中的指令更新生成文件；失败时立即停止
go generate ./...

# 只有生成成功后，才编译并运行全部包测试
go test ./...

在 CI 中也可以把它拆成两个阶段：第一阶段运行 go generate ./...，然后检查工作区是否出现未提交差异；第二阶段运行 go test ./...。是否把生成文件提交到仓库，要按团队策略决定。提交生成文件便于消费者直接构建，但必须记录生成器版本；不提交则要求每个构建环境都能安装同一版本的生成器。

遇到“测试前没生成”时按边界排查

先不要给 go test 增加神秘参数，可以按下面的顺序判断：

1. 执行 go generate -n ./...，先看将要运行哪些命令；-n 只打印，不真正执行。
2. 确认 //go:generate 没有缩进，生成器在当前环境的 PATH 中可用，输出路径也确实属于目标包。
3. 单独执行 go generate ./...，把“生成器启动失败”和“生成后的 Go 代码编译失败”分开记录。
4. 生成成功后再执行 go test ./...；若仍失败，问题已经进入普通编译或测试阶段。

常见坑是只在本地生成过一次，于是本地测试一直通过，干净 CI 却报缺少类型。另一个坑是生成器使用浮动版本，导致同一份输入在不同机器上产生不同输出。对这两类问题，显式流程和版本固定比修改测试命令更有效。

相关问题

可以把 go generate 放进 go test 的别名吗？

可以在 Makefile、脚本或 CI 任务中组合，但这属于项目入口约定，不是 go test 自身的内置行为。

生成文件一定要提交到 Git 吗？

不一定。提交能减少消费者的工具依赖；不提交则要保证构建环境可重复安装生成器，并在流水线里先生成。

go generate -n 能检查生成结果吗？

不能。它只能展示将执行的命令，真正的输出文件和生成器错误要通过一次正常的 go generate 检查。

为什么生成成功后测试仍然失败？

生成命令成功只说明生成器退出正常，生成代码仍可能有编译错误或业务逻辑问题；继续看 go test 的编译和断言信息即可。

记住这条边界就够了：go generate 负责把输入变成源码，go test 负责验证当前源码。想让它们连续发生，就在工程入口中明确写出两条命令。