接触 Go 并发模型时，最容易踩的一个坑是：main 函数返回后，整个进程直接退出，其他 Goroutine 会被无声地终止。假设你写了一个异步写日志的 Goroutine，或者启动了几个后台 worker，只要主函数执行完毕，这些任务大概率还没跑完程序就结束了。这是因为 Go 运行时不会等待普通 Goroutine 完成，main 函数返回相当于触发进程退出。因此，理解如何在 Go 中阻塞主 Goroutine，是写出可靠并发程序的基本功。
主 Goroutine 退出会带来什么
先看一个最简单的例子。下面这段代码在 main 函数中启动了三个 worker Goroutine，每个 worker 会先休眠 200 毫秒再打印完成信息。
package main
import (
"fmt"
"time"
)
func worker(id int) {
time.Sleep(200 * time.Millisecond)
fmt.Println("worker", id, "done")
}
func main() {
for i := 1; i <= 3; i++ {
go worker(i)
}
// main 很快返回，可能看不到任何输出
}
实际运行这段代码，很可能看不到任何输出。原因在于 main 函数在启动完 Goroutine 后立刻返回，进程退出时所有 Goroutine 都会被终止，根本没有机会执行到打印语句。即使某些极端情况下调度器抢在 main 返回前执行了 worker，输出也不完整、不稳定。这个例子说明：如果希望后台任务可靠执行，就不能让 main 函数直接结束。
一种临时做法是在 main 末尾加上 time.Sleep，比如睡上一秒。但这种方式非常脆弱，任务执行时间稍微变长就会出问题，而且它只能等待固定时长，无法感知任务是否真正完成。正确思路是让主 Goroutine 进入阻塞状态，直到满足某个条件后再退出。接下来看看几种实现阻塞的方式。
用空 select{} 和 nil 通道实现永久阻塞
Go 语言里最直接的永久阻塞写法是空 select 语句。select 通常用于监听多个通道操作，当它没有任何 case 时，当前 Goroutine 会永远挂起，并且会让出所占用的调度资源，不会消耗 CPU。
package main
import (
"fmt"
"time"
)
func main() {
go func() {
time.Sleep(time.Second)
fmt.Println("后台任务完成")
}()
select{} // 永久阻塞主 goroutine
}
执行这段代码后，程序不会退出，后台 Goroutine 在休眠一秒后会打印完成信息。空 select 的原理是它没有任何可以触发的通信操作，调度器会把这个 Goroutine 置为阻塞状态，因此它不是忙等。与之类似的是从 nil 通道接收数据。Go 中 nil 通道上的发送和接收都会永久阻塞，因为没有任何 Goroutine 能与之配对。
package main
func main() {
var ch chan int
<-ch // 从 nil channel 接收，永久阻塞
}
这两种写法的共同点是简单，适合主程序只需要挂在那里、后台 Goroutine 自行运行的场景。缺点是它们没有任何退出机制，一旦使用，程序只能通过外部信号强制杀死。对于一个需要优雅关闭的服务来说，这还不够。另外要特别注意，空 select 和 nil 通道接收都属于真正的阻塞，而 for{} 无限循环不是阻塞，它会让一个 CPU 核心持续空转，最终把资源耗尽。
用 sync.WaitGroup 等待任务完成
如果需要阻塞主 Goroutine 直到一批并发任务全部完成，sync.WaitGroup 是最合适的工具。它内部维护一个计数器，Add 方法增加计数，Done 方法减少计数，Wait 方法会阻塞到计数器归零。
package main
import (
"fmt"
"sync"
)
func worker(id int, wg *sync.WaitGroup) {
defer wg.Done()
fmt.Printf("worker %d started\n", id)
// 模拟耗时操作
}
func main() {
var wg sync.WaitGroup
for i := 1; i <= 5; i++ {
wg.Add(1)
go worker(i, &wg)
}
wg.Wait() // 阻塞直到所有 worker 调用 Done
fmt.Println("all workers done")
}
上面的循环在每次启动 worker 前调用 wg.Add(1)，主 Goroutine 执行 wg.Wait() 时会被阻塞，直到五个 worker 都执行完 defer wg.Done()。这是一个带明确结束条件的阻塞方式，比空 select 和 time.Sleep 都可靠得多。需要注意的是，Add 调用应该放在启动 Goroutine 的循环中，而不是放在 worker 函数内部。如果所有 worker 都在 goroutine 内部才 Add，可能出现主 Goroutine 已经执行到 Wait 时计数器仍为零的情况，导致 Wait 提前返回。
WaitGroup 非常适合批量任务、并发请求、worker 池等场景。不过它只解决等待任务完成的问题，并不提供外部退出信号。如果程序是一个长时间运行的服务，主 Goroutine 可能需要等待的是操作系统信号，而不是所有任务自然结束。
用 channel 接收退出信号和系统信号
通过 channel 也可以实现只阻塞到某个条件成立。常见做法是创建一个 done channel，worker 完成后往里面发送一个值，主 Goroutine 从通道接收数据，这个接收操作会阻塞主 Goroutine。
package main
import (
"fmt"
"time"
)
func worker(done chan struct{}) {
time.Sleep(300 * time.Millisecond)
fmt.Println("worker finished")
done <- struct{}{}
}
func main() {
done := make(chan struct{})
go worker(done)
<-done // 阻塞直到 worker 发信号
fmt.Println("main exits")
}
这种写法和 WaitGroup 有相似的效果，但 WaitGroup 更适合批量任务，而 done channel 更灵活，可以携带数据、可以在多个 Goroutine 之间传递明确的完成事件。比如你可以定义 chan error，让 worker 返回错误，主 Goroutine 接收后决定是否继续等待。
对于常驻服务，更实用的方式是阻塞等待系统信号。下面这段代码使用 signal.Notify 把 SIGINT 和 SIGTERM 转发到一个通道，主 Goroutine 从通道接收信号时会一直阻塞，直到用户按下 Ctrl+C 或进程收到终止信号。
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
)
func main() {
ch := make(chan os.Signal, 1)
signal.Notify(ch, syscall.SIGINT, syscall.SIGTERM)
go func() {
// 模拟后台服务
fmt.Println("service running...")
select{}
}()
sig := <-ch // 阻塞直到收到信号
fmt.Println("received signal:", sig)
// 执行清理逻辑
}
收到信号后，程序可以执行清理工作，比如关闭数据库连接、刷写日志、通知其他 Goroutine 停止，然后再返回。这样既实现了阻塞，又保留了优雅退出的能力。实际项目中还可以结合 context.WithCancel，在收到信号后取消 context，把退出通知传递给所有依赖该 context 的 Goroutine。
选择建议与常见误区
总结一下，不同的阻塞方式适合不同场景。只要求程序永久挂起，select{} 或 nil 通道接收最简洁；要等待一组并发任务完成，sync.WaitGroup 最直观；要等待单个完成事件，done channel 更灵活；要响应操作系统退出信号，则应该使用 signal.Notify 配合通道接收。
需要警惕的是忙等误区。有些开发者会用 for{} 循环来“阻塞”主 Goroutine，这其实是在让 CPU 空转。一个空 for 循环会让一个核心使用率直接拉满，调度器也无法回收时间片。即使加上 runtime.Gosched() 也只能部分缓解，绝不能把它当作阻塞手段。time.Sleep 虽然会让出 CPU，但它只能等待固定时间，无法感知任务完成或外部事件，因此在正式代码中也不适合作为主要的阻塞方案。
最后还要分清阻塞与休眠的区别。真正的阻塞会让 Goroutine 从调度队列中移除，不消耗 CPU；休眠只是让 Goroutine 在计时器上等待，到期后继续运行。理解这一点，才能根据是否需要等待、等待什么条件，选出正确的阻塞方式，避免写出既占资源又难维护的并发代码。