go fix modernizers 批量迁移旧标准库写法

旧 Go 项目常把 interface{}、旧构建标签或手写兼容辅助函数留在代码里。迁移时我更愿意先让 go fix 只展示候选差异，再选择 modernizer 批量落盘：这样既能收获新语言和标准库写法，也不会把一次大改误当成“自动完成”。官方资料显示，Go 1.26 重写了 go fix，它会按当前构建配置分析包，并提供一组 modernizers。

官方地址：https://go.dev/doc/

先预览 modernizers，再决定批量范围

第一步是确认工作区可回退。让 Git 工作区保持干净，便于把后续差异全部归因到 go fix。然后列出 fixer；不同 Go 工具链的清单会变化，所以不要把网上旧文章里的名称当成当前清单。

# 先确认工具链和可用的 modernizer 名称
go version
go tool fix help

# 只生成差异，不修改源文件
go fix -diff ./...

如果差异里出现 any、buildtag 或 fmtappendf 等明确 fixer，可以把它当作迁移候选。-diff 输出的是决策材料，不是测试结果；尤其要留意公共 API、序列化结果和空值行为。

用 fixer 开关控制旧写法迁移

确认范围后再落盘。想先处理一类写法，就使用对应的开关；需要排除某个 fixer，则将它设为 false。下面的命令适合放在迁移分支中执行：

# 只迁移明确选择的写法，命令前的注释说明本轮边界
go fix -any -buildtag ./...

# 预览所有 fixer，但暂时排除 any，避免一次改动过宽
go fix -diff -any=false ./...

不要把 fixer 名称当成“语义等价”的保证。例如某些旧写法在空切片、反射、序列化或公开库兼容性上有隐含行为，批量替换前应读差异并补针对性测试。modernizer 适合消除重复迁移劳动，最终取舍仍属于代码维护者。

按构建配置补齐平台文件，再做回归检查

go fix 每次只分析一个具体构建配置。项目含有 //go:build、平台专用文件或不同 CPU 路径时，只跑默认配置可能漏改。可以在迁移分支按项目实际支持的组合逐一预览和执行：

# 每条命令都绑定一个构建配置，便于把差异分组审查
GOOS=linux GOARCH=amd64 go fix -diff ./...
GOOS=darwin GOARCH=arm64 go fix -diff ./...
GOOS=windows GOARCH=amd64 go fix -diff ./...

确认三组差异后，再去掉 -diff 执行。平台数量不必机械扩张到所有组合，优先覆盖发布、CI 和实际支持的目标。迁移结束后先格式化，再检查差异和测试：

# 格式化只处理已经接受的改动
gofmt -w ./path/to/changed.go

# 先看改了什么，再验证包和测试
git diff --check
git diff --stat
go test ./...

哪些差异需要人工停下来判断

这里最容易踩的坑是“改完能编译，所以一定等价”。例如标准库新 API 可能改变空值表现；Go 官方文章也提醒过类似 modernizer 因空切片语义差异而不能直接纳入批量修复。迁移的验收标准应包括行为断言、跨平台构建和可读 diff。

常见问题

go fix 会默认修改生成文件吗？

官方说明中，触及生成文件的修复会被丢弃；生成逻辑应在源生成器侧更新。仍建议把生成目录的差异单独检查。

为什么同一项目要运行多次 go fix？

一次修复可能让另一个 modernizer 出现更清晰的匹配机会，也可能不同平台文件在不同配置下才可见。每轮都应保留差异并重新测试。

是否应该把所有 fixer 一次打开？

小型内部项目可以先预览全量差异；公共库或大仓库更适合按 fixer 分组，逐组审查 API、零值、序列化和最低 Go 版本。

把 go fix 当作可审查的迁移助手，核心节奏就是“干净分支、先看 diff、按构建配置覆盖、测试后清理”。这样批量现代化才不会变成一次难以定位的全仓库重写。