用 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；不带判断的接收也会返回零值，但无法区分是“刚关闭”还是“还没写入”。这是最容易踩的坑。
立即学习“go语言免费学习笔记（深入）”；
- 关闭 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 关闭状态的误判，往往出现在没有统一读取约定的多人协作代码里。
