从顺序执行到并发执行#

练习模拟的是”发起 3 个请求，每个耗时 1 秒”。顺序执行的版本要 3 秒才能跑完：

1
// 顺序请求数据（已注释）：总共约 3 秒
2
// axios("1")
3
// axios("2")
4
// axios("3")

Go 里把函数变成并发执行，只需要在调用前加 go：

1
func axios(id string, wait *sync.WaitGroup) {
2
  fmt.Println(id + "请求数据")
3
  time.Sleep(time.Second)
4
  fmt.Println("响应数据")
5
  wait.Done() // 完成一个，计数减一
6
}
7

8
var wait sync.WaitGroup
9
wait.Add(3) // 总共要等 3 个
10
go axios("1", &wait)
11
go axios("2", &wait)
12
go axios("3", &wait)
13
wait.Wait() // 阻塞在这里，直到计数归零
14

15
fmt.Println("获取数据结束")

为什么需要 WaitGroup#

main 函数返回时，程序直接退出，不会等任何协程。 如果没有 wait.Wait()，main 启动 3 个协程后立刻走完，协程还没来得及打印就被”连锅端”了。sync.WaitGroup 就是专门解决”等一组协程全部完成”的计数器：

• Add(3)：声明要等 3 个任务；
• 每个协程干完活调用 Done()：计数减一；
• Wait()：阻塞，直到计数归零才放行。

注意 &wait 传的是指针——WaitGroup 内部维护计数，必须传地址才能让所有协程操作同一个计数器。

实际运行输出：

1
1请求数据
2
3请求数据
3
2请求数据
4
响应数据
5
响应数据
6
响应数据
7
获取数据结束

两个观察：

1. 启动顺序不等于执行顺序：1 3 2 的打印顺序是随机的，协程由 Go 调度器安排，谁先跑不一定，多跑几次顺序会变。
2. 3 个 1 秒的任务几乎同时完成：三个”响应数据”扎堆出现，总耗时约 1 秒而不是 3 秒——这就是并发的意义。

小建议：实际项目里 wait.Done() 更稳妥的写法是 defer wait.Done() 放在函数开头，这样即使中途 return 或 panic 也不会漏掉计数。

无缓冲信道的发送与接收#

1
// 长度（容量）为零的信道，即无缓冲信道
2
var moneyChan = make(chan int)

信道用 make(chan 类型) 创建，操作符是 <-，方向决定读写：

1
moneyChan <- money // 发送：数据流向信道
2
money := <-moneyChan // 接收：数据从信道流出

练习场景：3 个协程各自”购买物品”花掉一笔钱，把金额通过信道发回 main 汇总：

1
func pay(id string, money int, wait *sync.WaitGroup) {
2
  fmt.Println(id + "购买物品")
3
  time.Sleep(time.Second)
4
  fmt.Println("购买完成")
5
  moneyChan <- money // 发送数据到信道
6
  wait.Done()
7
}

无缓冲信道的特性是同步：发送方会阻塞到有人接收，接收方会阻塞到有人发送，两边必须”碰头”才能完成一次传输。

close 与 range：谁来收尾#

main 里用 range 持续接收信道数据：

1
go func() {
2
  wait.Wait()
3
  close(moneyChan)
4
}()
5

6
for money := range moneyChan { // 修正后的写法，详见下文
7
  moneyList = append(moneyList, money)
8
}
9
fmt.Println("消费结束")

range 信道 会一直接收，直到信道被 close 才结束循环。如果没人 close，range 会永远阻塞下去（协程都退出后还会报 deadlock）。但 close 的时机有讲究：必须等所有发送方发完才能关，否则往已关闭的信道发送会 panic。

代码里的解法是一个很经典的模式——单独起一个协程专门负责关闭：

• main 自己不能先 wait.Wait() 再 range，那样 main 阻塞在 Wait 上时没人接收，发送方全卡住，死锁；
• 所以把”等待+关闭”交给另一个协程，main 只管专心接收。

抓到一个 bug：range <-moneyChan#

我最初写的代码其实是这样（多了个 <-）：

1
for money := range <-moneyChan { // 错误写法！
2
  moneyList = append(moneyList, money)
3
}

它能编译、能运行、还不报错，但行为完全不对。我在临时环境把 moneyList 打印出来对比：

1
原代码（range <-moneyChan）：[0 1 2 3 4]
2
修正后（range moneyChan）：  [5 20 10]

原因：range 后面的表达式是 <-moneyChan，这是”从信道接收一个值”，类型是 int。而 Go 1.22 起允许对整数 range（for i := range n 循环 0 到 n-1）。于是这行代码的真实执行过程是：

1. 从信道接收一个金额（比如某个协程发的 5）；
2. 把这个 5 当成循环次数，money 依次等于 0、1、2、3、4；
3. 收集到的全是循环下标，真正的 5、10、20 全丢了。

这也解释了为什么运行时”消费结束”会抢在最后一个”购买完成”之前打印——main 只接收了一次就循环完走人了，根本没等其他协程。如果在 Go 1.22 之前，这种写法会直接编译报错，是 range-over-int 新特性让它变成了”安静的错误”。教训：range 信道时信道变量前不要加 <-。

另外一个小提醒：原代码里 moneyList 收集了数据却从没打印或使用，练习时可以加一行 fmt.Println(moneyList) 确认结果。