在 Go 的并发代码里，sync.WaitGroup 几乎是每个开发者都会反复接触的同步工具，但它长期伴随的一段固定模板，也一直在制造重复劳动和低级失误。Go 1.25 新增的 WaitGroup.Go()，正是针对这个老问题做的一次小而准的改进：先看它替你省掉了什么，再判断它是否值得在项目里优先采用。
传统 WaitGroup 写法，问题不在能不能用
过去我们最熟悉的写法通常是这样：
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
// 执行业务逻辑
}()
wg.Wait()这套模式从 Go 1.0 开始就非常常见，也确实能完成 goroutine 协调。但它的问题并不是“不可用”，而是每次都要手动维护一组固定动作，久而久之既容易出错，也会让业务代码被同步细节包住。
放到更完整的场景里，这种感觉会更明显：
func processItems(items []string) {
var wg sync.WaitGroup
for _, item := range items {
wg.Add(1)
go func(i string) {
defer wg.Done()
process(i)
}(item)
}
wg.Wait()
}这类代码主要有三个痛点。
重复模板多，读写成本都高
每启动一个 goroutine，往往都要补上 wg.Add(1) 和 defer wg.Done()。这些语句本身没有业务含义，却必须不断重复出现。写的人会嫌繁琐，读的人也要先跨过这层样板，才能看到真正的处理逻辑。
容易漏掉关键调用
WaitGroup 的使用很依赖纪律：少写一次 Add(1)，或者忘记 Done()，就可能埋下同步 BUG。很多问题不是因为机制复杂，而是因为模板代码全靠手写，出错点天然更多。
核心意图不够直接
当同步代码占据太多位置时，读者第一眼看到的是“怎么收尾”，而不是“这个 goroutine 到底在做什么”。尤其在并发任务较多时，代码表达会显得偏重样板、偏轻意图。
Go 1.25 的 `wg.Go()` 到底做了什么
Go 1.25 给 sync.WaitGroup 加入了一个新方法：
func (wg *WaitGroup) Go(f func())它的用法很直接：
var wg sync.WaitGroup
wg.Go(func() {
// 执行业务逻辑
// 无需手动调用 Add 和 Done
})
wg.Wait()如果只看调用方式，可以把它理解成“把一个任务登记到 WaitGroup，并启动 goroutine 执行”。原来需要调用者自己维护的两个动作，现在被折叠进了标准库接口里。
它本质上封装了 `Add(1)` 和 `Done()`
这个方法的核心并不复杂，原理也非常透明：
func (wg *WaitGroup) Go(f func()) {
wg.Add(1)
go func() {
defer wg.Done()
f()
}()
}也就是说，Go() 并没有发明新的并发模型，而是把大家反复手写的标准模式收敛成一个官方入口。这样带来的价值，不在“功能变多”，而在“更不容易写错”。
`defer` 保证仍然保留
Go() 内部依旧使用了 defer wg.Done()。这点很关键，因为它保留了传统写法里最重要的正确性保障：无论任务函数如何退出，Done() 都会在返回路径上被触发，即使中间发生 panic，也不会因为漏写收尾而让等待逻辑失衡。
它解决的不是“写法丑”，而是并发代码里的真实摩擦
WaitGroup.Go() 看起来只是一个小改动，但它命中的恰好是并发代码里最常见的摩擦点。
少掉一层模板，业务逻辑更靠前
把前面的批量处理例子改写后，结构会更轻一些：
func processItems(items []string) {
var wg sync.WaitGroup
for _, item := range items {
wg.Go(func() {
process(item)
})
}
wg.Wait()
}这里最直观的变化是，循环内部只剩“启动一个并发任务并处理 item”这个核心动作。同步细节退到了方法内部，阅读路径会顺很多。
更少的手工步骤，通常就意味着更少的低级错误
传统写法要求调用者自己记住两件事：启动前先 Add(1)，函数返回前要 Done()。wg.Go() 把这两个步骤合并后，使用者只需要关心任务函数本身，遗漏同步调用的机会自然随之下降。
这也是它最实际的价值之一：不是提升并发性能，而是降低人为失误概率。
代码意图会更集中
当一个地方连续启动多个任务时，wg.Go() 的表达会更接近“列出并发工作项”：
// 一眼就能看出这是并发执行的任务
wg.Go(func() { fetchUser() })
wg.Go(func() { fetchOrder() })
wg.Go(func() { fetchProduct() })这段代码没有额外噪音，读者可以很快确认：这里并发发起了三个工作单元，最后再统一等待。对于维护者来说，这种清晰度很有价值。
什么时候适合优先使用 `WaitGroup.Go()`
如果你的项目已经升级到 Go 1.25，那么凡是符合“启动 goroutine 并纳入 WaitGroup 管理”的常规场景，基本都可以优先考虑 wg.Go()。它特别适合以下情况：
- 批量启动相似任务，需要快速看清并发结构
- 代码里大量重复出现
Add(1)+defer Done()模板 - 团队希望减少因为遗漏同步调用产生的机械性 BUG
反过来说，如果你所在环境还没有使用 Go 1.25，这个方法暂时就无法直接采用，仍然需要沿用传统模式。在这种情况下，至少也应该把 Add(1) 和 defer wg.Done() 保持成稳定、统一的写法，避免每个模块各写各的。
这个改动小，但很符合 Go 的演进方向
sync.WaitGroup.Go() 之所以值得关注，不是因为它增加了多少新能力，而是因为它把一个人人都在重复、又人人都可能写错的模式，收进了标准库的明确接口。
从结果上看，它带来的改进很具体：
- 简单优于复杂：把固定模板压缩成一次方法调用
- 效率优于形式：让开发者把注意力放回业务逻辑
- 实用优于理论：直接减少常见同步错误的入口
对于 Go 1.25 用户来说，这类改动的价值往往不在“惊艳”，而在“终于不用再手写那一段了”。如果一个标准库接口能让并发代码更短、更清楚，也更不容易漏掉关键步骤，那它就已经足够值得采用。
