为何导入RabbitMQ包后，Go中原本会死锁的代码不再报错？

常规场景下的死锁逻辑 #

如果这段代码里的msgs是一个无数据流入、也未被关闭的普通通道，会触发死锁的原因很直接：

• 子协程会永久阻塞在for d := range msgs——Go语言中，对未关闭的空通道执行range会一直等待数据，不会退出。
• 主协程同时阻塞在<-forever——这个通道没有任何goroutine会发送数据进去。
  此时程序中所有活跃的goroutine都处于阻塞状态，没有任何执行路径能打破这个僵局，Go runtime的死锁检测机制就会抛出错误。

导入RabbitMQ包后的核心变化 #

当你引入RabbitMQ的Go客户端包（比如常用的streadway/amqp）后，msgs是通过Channel.Consume()获取的消费通道，此时有两个关键因素避免了死锁：

1. 后台活跃goroutine存在：RabbitMQ客户端会自动启动多个后台goroutine，负责维护与服务器的TCP连接、发送心跳包、监听服务器的消息推送等。这些goroutine始终处于运行状态（不会阻塞），所以程序中并非所有goroutine都陷入阻塞，Go runtime不会判定为死锁。
2. 消费通道的动态行为：
   • 只要RabbitMQ队列中有消息，服务器就会持续推送数据到msgs通道，子协程的for range会持续处理消息，不会一直阻塞。
   • 即使队列暂时无消息，子协程的阻塞也只是局部状态，后台的客户端goroutine仍在运行，不会触发全局死锁。
   • 当连接断开、通道关闭或消费者被取消时，客户端会主动关闭msgs通道，子协程的for range会正常退出，但主协程仍会阻塞在<-forever——这是代码设计的“永久等待”逻辑，并非死锁。

内容的提问来源于stack exchange，提问作者wyatt j