Go fix 修改代码后为什么需要重新检查生成文件

升级 Go 工具链后，go fix ./... 可能一次改动很多文件。真正容易出错的地方不是“命令会不会改代码”，而是把生成文件当成手写文件继续 review。Go 官方说明明确指出：如果某个 fix 会碰到生成文件，改动会被丢弃；正确的修复位置应当是生成器逻辑。也就是说，生成文件需要回到输入源和生成命令重新处理。

官方文档：https://go.dev/doc/cmd

先用 go fix -diff ./... 看补丁，再确认生成文件的来源；需要改变生成结果时，修改生成器或输入文件，显式重跑生成命令，最后把手写改动和生成改动分开 review。

go fix 先改哪里，为什么会跳过生成文件

go fix 的定位是把旧的语言或库用法迁移到更新的写法。它可以接收包模式，例如下面的命令覆盖当前模块下的包：

# 先只查看统一 diff，不直接改写工作区
go fix -diff ./...

官方命令文档还说明，-diff 会输出统一补丁；有补丁时命令以非零状态结束。这样做的价值是先看“哪些手写源文件会变化”，再决定是否应用。Go 1.26 的新版 go fix 还会丢弃触及生成文件的修复，因为生成文件下一次重建时会被覆盖，直接修改它不能稳定解决问题。

可以把边界记成一句话：go fix 负责迁移可维护的源码，生成器负责产生可重复的结果。如果 review 里只看到某个 *.pb.go、zz_generated.go 或其他带生成标记的文件发生手改，就应该先追溯它的输入，而不是马上接受这段 diff。

生成文件变化时，先找真正的输入源

生成文件通常不是独立源代码。常见链路是：手写的接口或 schema 触发 //go:generate，生成器读取输入后写出 Go 文件。Go 官方文档特别强调，go generate 不会被 go build、go test 自动调用，必须显式运行。

//go:generate go run ./cmd/gen -input schema.json -output zz_generated.go

package profile

// Profile 是手写源码中的稳定输入模型；生成器会读取 schema，而不是依赖这段注释本身推断业务规则。
type Profile struct {
	Name string `json:"name"`
}

排查时按下面的最小顺序即可：

1. 先用 git diff 看 go fix -diff 提议的文件，标出生成文件。
2. 搜索 //go:generate、README 中的生成命令和构建脚本，确认生成器入口。
3. 判断应修改的是 schema、模板、生成器代码，还是 Go 版本升级带来的手写调用方式。

如果生成文件只是因为上游输入变化而需要更新，就应该先改输入或生成器，再显式执行生成命令。不要为了让当前构建通过而直接编辑生成结果，否则下一次生成会把补丁覆盖，review 也很难判断改动来源。

一套不容易误提交的最小流程

实际迁移可以固定成“预览—应用—重生成—整理—测试—审阅”这一组动作。这里的关键不是把每条命令串成脚本，而是让每个 diff 都有清楚的来源。

# 先从干净工作区开始，确保 diff 只来自本轮迁移
git status --short

# 预览 go fix 将要提出的补丁；有补丁时命令可能返回非零状态
go fix -diff ./...

# 确认预览无误后才应用修复
go fix ./...

# 生成命令必须显式执行，输出由输入文件和生成器决定
go generate ./...

# 统一格式，避免生成器或迁移造成无关排版差异
gofmt -w .

# 测试编译结果和行为
go test ./...

# 最后按文件来源检查变更
git diff --stat
git diff -- '*.go' 'go.mod' 'go.sum'

其中 gofmt -w . 会把当前目录交给格式化命令；在大型仓库里，也可以把范围收窄到本次涉及的包。更重要的是，不要把 go test 当成生成步骤：测试通过只说明当前工作区能构建和运行，不代表生成文件已经和输入源同步。

review 时重点看这四个边界

如果只想知道某个 fixer 会做什么，可以查看可用分析器：

# 查看当前工具链提供的 fixer 列表
go tool fix help

# 查看某一个 fixer 的说明，不把它当成生成器替代品
go tool fix help forvar

常见误区

• 误区一：生成文件没有变化，就说明迁移完成。不一定。go fix 可能只处理手写调用点，生成器仍需要按新的输入或工具链重新生成。
• 误区二：生成文件有编译错误，就直接手改。先确认错误来自生成器模板、输入 schema 还是生成器依赖；手改输出通常不可持续。
• 误区三：看到 go generate 就认为 build 会自动执行。生成命令需要显式调用，构建和测试不会替你补跑。

相关问题

go fix 和 gofmt 是一回事吗？

不是。gofmt 主要统一源码格式，go fix 根据分析器提出语言或库用法迁移；两者可以连续使用，但职责不同。

为什么要从干净的 git 状态开始？

因为 go fix 可能改很多文件。干净工作区能让 review 直接看到本轮迁移的来源，减少把旧改动误认为自动修复的风险。

生成器重跑后仍有 diff 怎么办？

把 diff 分成输入变化、生成器变化和工具链变化三类，再逐类确认。若同样输入每次都产生不同输出，还要先处理生成器的确定性问题。