goroutine泄露因通道未关闭或缺少退出机制导致，需用context控制生命周期并确保channel由发送方关闭，接收方通过range或ok判断结束，select中应监听ctx.Done()避免永久阻塞。
在Golang中，goroutine泄露是指启动的goroutine无法正常退出，导致它们一直占用内存和系统资源。这种情况通常发生在goroutine等待接收或发送数据时，而对应的通道（channel）再也没有被关闭或写入，使goroutine永远阻塞。为了避免这类问题，关键在于确保每个goroutine都能在适当的时候终止。
使用context控制goroutine生命周期
context是控制goroutine生命周期最有效的方式之一。通过传递context，可以在外部主动取消一组goroutine，尤其是在超时、请求取消或程序退出时非常有用。
例如：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()go func(ctx context.Context) { for { select { case <-ctx.Done(): fmt.Println("goroutine exiting due to context cancellation") return default: // 执行一些工作 time.Sleep(1 * time.Second) } } }(ctx)
// 主程序等待或做其他事 <-ctx.Done()
只要调用cancel()，所有监听该context的goroutine都会收到信号并退出。
立即学习“go语言免费学习笔记（深入）”；
确保channel有明确的关闭机制
当goroutine在从channel读取数据时，如果channel永远不会关闭，且没有更多数据写入，goroutine就会永久阻塞。
正确做法是：由发送方在不再发送数据时关闭channel，接收方通过通道的“ok”值判断是否已关闭。
示例：
ch := make(chan int)
go func() {
for value := range ch { // range会自动检测channel关闭
fmt.Println("Received:", value)
}
fmt.Println("Goroutine exiting...")
}()
// 发送数据
ch <- 1
ch <- 2
close(ch) // 关键：关闭channel以通知接收方结束
time.Sleep(time.Second)
如果不close(ch)，range将永远等待下一个值，造成泄露。
避免在select中漏掉退出条件
多个channel操作常使用select，但若未处理退出信号，goroutine可能无法终止。
常见错误写法：
ch1, ch2 := make(chan int), make(chan int)
go func() {
for {
select {
case v := <-ch1:
fmt.Println(v)
case v := <-ch2:
fmt.Println(v)
}
}
}()
这个goroutine没有退出路径。应加入context或done channel：
done := make(chan struct{})
go func() {
defer close(done)
for {
select {
case v := <-ch1:
fmt.Println(v)
case v := <-ch2:
fmt.Println(v)
case <-done:
return
}
}
}()
监控和调试潜在的goroutine泄露
可通过runtime.NumGoroutine()粗略查看当前运行的goroutine数量，辅助判断是否存在泄露。
更推荐使用pprof进行分析：
import _ "net/http/pprof" // 启动服务后访问 /debug/pprof/goroutine 可查看goroutine堆栈
定期检查可以发现异常增长的goroutine数量，及时定位问题。
基本上就这些。只要保证每个goroutine都有明确的退出机制，使用context管理生命周期，合理关闭channel，并在select中处理退出信号，就能有效避免goroutine泄露。不复杂但容易忽略细节。
