为何需在独立Go协程中调用wg.Wait()与close()？

我有大量包含数百至数千文件的目录，希望遍历这些目录，为每个目录启动Go协程扫描文件，并将每个文件路径加入任务队列供工作协程处理。目前我的代码实现如下：

type AppConfig struct {
    UploadPath string `mapstructure:"upload_path"`
    LocalPath  string `mapstructure:"local_path"`
    Bucket     string `mapstructure:"bucket"`
}

func consumer(i int, jobs <-chan *ops.Job) {
    defer wg.Done()
    for job := range jobs {
        fmt.Printf("Worker: %v is processing file: %v\n", i, job.Work)
    }
}

func producer(jobs chan<- *ops.Job, filesToTransfer []string) {
    for i, file := range filesToTransfer {
        jobs <- &ops.Job{Id: i, Work: file}
    }
}

func main() {
    var (
        appconfigs map[string]*ops.AppConfig
        wg *sync.WaitGroup
    )

    jobs := make(chan *ops.Job)

    // setting up workers
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go consumer(i, jobs)
    }

    // adding jobs
    for _, values := range appconfigs {
        filesToTransfer := ops.ScanUploadPath(values.LocalPath)
        go producer(jobs, filesToTransfer)

    }

    go func() {
        wg.Wait()
        close(jobs)
    }()
}

此前我将close(jobs)调用放在producer函数中时，遇到了死锁和通道关闭panic问题。查阅资料后改为在main()中通过独立Go协程执行上述操作，但我并不理解为何需要在producer之外使用独立协程，希望有人能解释原因。

一、把close(jobs)放在producer里的问题根源 #

• 多生产者下的panic风险：你启动了多个producer协程，每个对应一个目录扫描。如果其中某个producer先完成文件遍历就调用close(jobs)，其他还在运行的producer再往已关闭的通道发送数据，会直接触发send on closed channel的panic。
• 死锁隐患：就算你想只让最后一个完成的producer关闭通道，也没法精准判断哪个是最后一个。判断早了，通道提前关闭，消费者会退出，剩下的producer发数据时因为没接收者而阻塞；判断晚了，所有producer都完成后，消费者会一直卡在range jobs上等待新任务，最终整个程序死锁。

二、独立协程执行wg.Wait()+close(jobs)的必要性 #

1. 避免main阻塞导致的连锁阻塞：如果直接在main里调用wg.Wait()，main会一直阻塞到所有消费者完成。但你的jobs通道是无缓冲的，producer发送数据需要消费者实时接收。一旦main阻塞，producer可能因为没有消费者接收数据而卡住，反过来消费者也拿不到任务，形成死锁。把等待逻辑放到独立协程，main可以继续运行，保证所有producer能顺利把任务发完。
2. 确保通道在合适时机关闭：wg.Wait()会等待所有10个消费者协程执行完毕，此时意味着所有任务都已经处理完成。这时候关闭通道是安全的——不会有producer再往通道发数据，消费者的range循环也会因为通道关闭而正常退出，然后执行defer wg.Done()完成收尾。

简单来说，这个独立协程的作用就是让任务发送和任务处理的流程互不阻塞，同时保证通道在所有任务处理完毕后安全关闭，彻底解决之前的panic和死锁问题。

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