Go嵌套goroutine同步时WaitGroup计数器为负报错如何解决

核心原因 #

• 首先你违反了sync.WaitGroup的核心使用规则：Add方法必须在启动对应goroutine之前调用，不能放在goroutine内部执行。你在fetch的匿名请求goroutine里，把启动insertPosts对应的group.Add(1)放在了HTTP请求、JSON解析逻辑之后，这时候很可能外层的初始goroutine已经全部执行完Done，WaitGroup计数器已经降到0，等你这里Add(1)之后再执行Done，就会把计数器减为负数触发panic。
• 第二个问题：初始wg.Add(4)配置错误，你实际只有3个需要等待的顶层goroutine（insertTags、fetch、addPostToTree），多余的1次Add会导致WaitGroup永远不会结束，容易引发连锁的并发错误。
• 第三个隐藏问题：fetch的循环里存在闭包变量捕获错误，循环变量ep会被所有启动的匿名goroutine共享，实际执行时大部分goroutine拿到的都是最后一次循环的ep值，请求结果完全不符合预期。
• 第四个问题：postChan没有正确关闭，导致addPostToTree里的for range永远阻塞，永远不会调用defer group.Done()，第一次请求能跑完大概率是巧合，高并发下必然出现阻塞。

修复方案 #

1. 修正WaitGroup使用和闭包问题，所有Add调用移到对应goroutine启动之前：

// fetch内启动请求goroutine的逻辑修改
group.Add(1)
go func(ep *url.URL) { // 把ep作为参数传入，解决闭包捕获问题
    defer group.Done() // 放函数最开头，避免后面逻辑提前return漏执行
    resp, err := http.Get(ep.String())
    if err != nil {
        errs <- err
        return
    }
    defer resp.Body.Close() // 放在resp非空判断之后，避免空指针panic
    container := models.PostContainer{}
    if err = json.NewDecoder(resp.Body).Decode(&container); err != nil {
        errs <- err
        return
    }
    group.Add(1) // 启动insertPosts前先调用Add
    go insertPosts(posts, container.Posts, group)
}(ep) // 把当前循环的ep值作为参数传入匿名函数

2. 调整channel关闭逻辑：

• tagChan你现在的关闭位置是对的，insertTags遍历完所有标签后关闭即可。
• 新增内部WaitGroup专门追踪请求和insertPosts的goroutine，全部执行完成后关闭postChan，让addPostToTree的遍历逻辑能正常退出：

func fetch(posts chan<- models.Post, tags <-chan string, errs chan<- error, group *sync.WaitGroup) {
    defer group.Done()
    var fetchWg sync.WaitGroup // 内部wg专门追踪所有请求、插入post的goroutine
    for tag := range tags {
        ep, err := formURL(tag)
        if err != nil {
            errs <- err
            continue
        }
        fetchWg.Add(1)
        go func(ep *url.URL) {
            defer fetchWg.Done()
            // ... 原有请求、解析逻辑 ...
            fetchWg.Add(1)
            go insertPosts(posts, container.Posts, &fetchWg)
        }(ep)
    }
    // 所有请求和插入post的goroutine跑完后关闭postChan
    go func() {
        fetchWg.Wait()
        close(posts)
    }()
}

• errChan的关闭逻辑保持不变，只要所有Done都正确执行，等主WaitGroup完成后关闭即可。

• 静态检查优先：执行go vet命令，可以直接检出闭包变量捕获、WaitGroup使用错误这类常规并发问题，排查成本最低。
• 竞态检测：编译或运行程序时加-race参数，能自动检测数据竞争、WaitGroup滥用等并发问题，会精准打印出问题发生的代码位置。
• pprof goroutine分析：给服务注册pprof路由后，访问/debug/pprof/goroutine?debug=2可以直接导出所有goroutine的调用栈，能快速定位阻塞的goroutine位置、泄漏的goroutine数量。
• 日志埋点：在goroutine启动和退出时打印带有唯一标识的日志，可以快速确认goroutine的生命周期是否符合预期。
• 动态调试：用delve调试工具打断点，查看实时goroutine列表、每个goroutine的运行状态、WaitGroup的计数器值，适合定位复杂并发问题。

内容的提问来源于stack exchange，提问作者cmt_