如何在Golang中处理goroutine间依赖_Golang channel同步与依赖控制实践

用 sync.WaitGroup 等待 goroutine 完成：Add(1) 必须在 go 前调用，Done() 推荐 defer 调用；需多个 goroutine 但只取首个结果时，用 select 监听同类型 channel 实现“first result wins”。

goroutine 启动后怎么等它做完再继续？

用 sync.WaitGroup 最直接。它不传数据，只管“有几个 goroutine 在跑、它们是否都结束了”。WaitGroup 的 Add 必须在 goroutine 启动前调用，否则可能 Wait 永远阻塞或 panic。

• Add(1) 要在 go func() {...}() 之前，不能写在 goroutine 内部
• 每个 goroutine 结束前必须调用 Done()，推荐用 defer wg.Done() 防遗漏
• 不要重复 Add 同一个 WaitGroup 多次却不 Done，会卡死

var wg sync.WaitGroup
wg.Add(1)
go func() {
    defer wg.Done()
    time.Sleep(100 * time.Millisecond)
    fmt.Println("done")
}()
wg.Wait() // 主协程在这里阻塞，直到上面的 goroutine 调用 Done

需要等多个 goroutine，但只关心“第一个返回的结果”？

用 select + chan 配合 default 或 context.WithCancel 控制超时，但更常见的是用 select 监听多个 chan，谁先发就收谁——这就是 “first result wins” 模式。

• 所有结果 channel 必须是同类型，比如 chan int
• 避免漏收：没被选中的 channel 会一直挂着，如果后续还要读，得确保有 goroutine 在持续写或关闭它
• 如果只想要第一个，其余 goroutine 应该能及时退出，否则浪费资源；可用 context.Context 通知取消

ch1 := make(chan string, 1)
ch2 := make(chan string, 1)
go func() { ch1 <- "from A" }()
go func() { ch2 <- "from B" }()
select {
case s := <-ch1:
fmt.Println(s)
case s := <-ch2:
fmt.Println(s)
}

goroutine A 必须等 goroutine B 发出信号才能开始？

用无缓冲 channel（make(chan struct{})）做“信号量”最轻量。它不传业务数据，只起同步作用，零内存开销，语义清晰。

• 发送方用 ch ，接收方用 阻塞等待
• 无缓冲 channel 的 send 和 receive 必须配对，否则会死锁；建议用 defer 确保发送一定发生
• 别用 int 或 bool 类型 channel 传信号——容易误读意图，也浪费空间

ready := make(chan struct{})
go func() {
    time.Sleep(50 * time.Millisecond)
    close(ready) // 或用 ready <- struct{}{}
}()
<-ready // 主协程在此阻塞，直到另一端发出信号
fmt.Println("now start")

channel 关闭后还能读吗？读完会怎样？

能读，但行为分两种：带 ok 判断的接收会返回零值 + false；不带判断的接收也会返回零值，但无法区分是“刚关闭”还是“还没写入”。这是最容易踩的坑。

• 关闭 channel 前确保没人再往里写，否则 panic：send on closed channel
• 多个 goroutine 从同一 channel 读没问题，但关闭只能由写方决定，且只能关一次
• 用 for range ch 自动处理关闭逻辑，比手动 更安全

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)
v, ok := <-ch // v==1, ok==true
v, ok = <-ch  // v==2, ok==true
v, ok = <-ch  // v==0, ok==false ← 注意：v 是 int 零值，不是错误

实际依赖控制中，WaitGroup 和 chan struct{} 解决“是否完成”，select 解决“谁先完成”，而 channel 关闭状态的误判，往往出现在没有统一读取约定的多人协作代码里。