Go go fix 为什么 waitgroup 检查器名称改变（参数形态）

我第一次在 Go 1.27 工具链里重新看 go fix 的帮助输出时，注意到熟悉的 waitgroup 不见了，取而代之的是 waitgroupgo。这不是检查能力突然消失，也不是命令从 go fix 改成了别的名字，而是 Go 团队给这个现代化器换了一个更能表达动作的名称：它关注的是把一组固定的 WaitGroup 写法改成 WaitGroup.Go。

官方资料：https://go.dev/doc/go1.27

先把“命令名称”和“检查器名称”分开

这个问题最容易卡在名词层面。go fix 是用户执行的命令，负责对指定包运行修复器并应用建议的修改；waitgroupgo 是其中一个 analyzer 的注册名。也就是说，变化发生在“子分析器如何命名”这一层，命令入口仍然是 go fix。

Go 1.27 的发布说明同时提到，go fix 增加了多个现代化器，并把原来的 waitgroup analyzer 改名为 waitgroupgo。我的理解是，这个名字把“检查 WaitGroup 误用”和“把旧写法现代化为 wg.Go”区分开了，读者看到名称就能预期它的改写方向。

用帮助输出确认当前工具链到底注册了什么

不要根据旧文章或旧脚本猜 analyzer 名称。先让当前 Go 工具链自己列出注册项：

# 只查看当前工具链提供的修复器名称，不修改项目文件
go tool fix help

# 只预览项目下所有包的修复差异，先不写回源码
go fix -diff ./...

帮助输出中应该能看到 waitgroupgo。如果脚本仍然传入旧的 waitgroup 选项，常见结果是“找不到该分析器”或没有按预期选中目标修复器。这个现象并不说明项目里的 sync.WaitGroup 失效，只说明脚本保存的是旧注册名。

官方命令文档还说明，go fix 的 -diff 会输出统一差异，并在存在差异时返回非零状态。它适合放进升级检查或 CI 预览步骤，但不能把非零状态简单当成编译失败。

waitgroupgo 为什么需要一个更具体的名字

旧名字 waitgroup 太宽泛：它既可以让人联想到“检查 WaitGroup 的错误用法”，也可能让人以为它负责所有 WaitGroup 相关迁移。Go 1.27 的 waitgroupgo 实际上对应一个更窄的现代化模式：把显式的计数、启动 goroutine 和 Done 配对，整理成 Go 1.25 引入的 WaitGroup.Go。

package worker

import "sync"

func runJobs(jobs []func()) {
	var wg sync.WaitGroup
	for _, job := range jobs {
		wg.Add(1) // 固定加一，表示下面只启动一个 goroutine。
		go func(fn func()) {
			defer wg.Done() // goroutine 退出时归还这一次计数。
			fn()
		}(job)
	}
	wg.Wait() // 等待已登记的任务全部结束。
}

在满足分析器识别条件的情况下，现代化后的形态会更接近下面这样：

func runJobs(jobs []func()) {
	var wg sync.WaitGroup
	for _, job := range jobs {
		wg.Go(func() {
			// Go 负责登记并在函数返回时完成 Done。
			job()
		})
	}
	wg.Wait()
}

这里的重点不是“看到 WaitGroup 就替换”，而是旧代码的计数、启动和收尾关系足够清楚，工具才能安全表达同一件事。名称改为 waitgroupgo，正好把这个目标写进了工具名。

先用 -diff 预览，再决定是否让 go fix 写回

我在升级工具链时会把修改分成两个动作：先看补丁，再应用补丁。这样可以把名称变化和实际源码变化分别处理，也能确认当前构建配置下哪些文件被分析。

# 在干净工作区先预览，不直接改文件
go fix -diff -waitgroupgo ./...

# 确认补丁只涉及预期模块后，再应用该现代化器
go fix -waitgroupgo ./...

如果希望运行默认修复器集合，可以只使用 go fix -diff ./...；如果要限定范围，再使用与 analyzer 同名的布尔选项。实际参数以当前版本的 go tool fix help 为准，旧版本的帮助输出不能替代本机确认。

还有一个容易被忽略的边界：go fix 每次只分析一个构建配置。如果项目有不同的 GOOS、GOARCH 或 build tag，预览结果只代表当前配置。需要覆盖多个目标时，应分别运行预览并分别审阅差异。

哪些 WaitGroup 代码不要机械改成 wg.Go

waitgroupgo 的价值在于减少重复的生命周期样板，不在于替工程师重新设计并发协议。下面几类代码即使涉及 WaitGroup，也不应该只因为名字变化就强行替换：

我的升级判断清单

名称改动本身不难，真正容易出错的是把“工具能识别”误当成“项目应该自动改”。我会按下面顺序处理：

1. 先确认项目使用的 Go 工具链和 go.mod 语言版本，避免用旧工具链解释新帮助输出。
2. 运行 go tool fix help，确认当前 analyzer 注册名是 waitgroupgo。
3. 用 go fix -diff 生成预览，把源码变化限制在当前构建配置可见的文件。
4. 重点审阅循环、条件分支、动态 Add、跨函数回调和错误处理，不把所有差异都视为机械格式化。
5. 确认测试和并发协议仍然成立后，再应用补丁并提交一组容易回滚的变更。

常见问题

waitgroup 改成 waitgroupgo 后，go fix 命令也改了吗？

没有。变化是 analyzer 的注册名；入口仍是 go fix，帮助命令仍是 go tool fix help。

为什么我的旧脚本找不到 waitgroup？

如果脚本把 analyzer 名称作为选项传入，Go 1.27 中应改用 waitgroupgo。先在目标环境运行帮助命令，不要直接照抄旧版本输出。

是不是所有 WaitGroup 都应该换成 wg.Go？

不是。工具针对的是可明确识别的固定模式；动态计数、条件启动或跨函数管理的代码需要先看差异并人工判断。

总结

这次改名的核心是减少歧义：waitgroupgo 更明确地指向“把符合模式的 WaitGroup 写法现代化为 wg.Go”。遇到名称变化时，先区分命令和 analyzer，再用本机帮助输出确认参数，最后通过 -diff 审阅实际代码变化。这样既能享受新工具链，也不会把并发协议交给一个过宽的自动化假设。