defer 语句仅在**所在函数返回时**触发执行；若 goroutine 是无限循环且永不返回，则其中的 defer 永远不会被调用，资源无法自动释放。
在 Go 中，defer 的行为严格绑定于函数生命周期：它会将函数调用压入一个栈（LIFO），并在当前函数即将返回前（包括正常返回、panic 后 recover 等所有退出路径）统一执行。这一点在官方博客 Defer, Panic, and Recover 中明确指出：“A defer statement pushes a function call onto a list. The list of saved calls is executed after the surrounding function returns.”
因此，当你在如下 goroutine 中使用 defer：
go func() {
defer conn.Close() // ❌ 永远不会执行！
defer ch.Close() // ❌ 同样不会执行！
for {
msgs, _ := ch.Consume(...)
for d := range msgs {
log.Printf("Received: %s", d.Body)
d.Ack(true)
}
time.Sleep(1 * time.Second)
}
}()由于该匿名函数永不返回（无限 for 循环），所有 defer 语句注册的清理逻辑将被永久挂起，导致 conn、ch 等资源长期泄漏——这不仅是语义错误，更是典型的生产环境隐患。
✅ 正确做法是：将资源生命周期与可控作用域对齐。常见方案包括：
显式关闭 + 退出信号控制（推荐）：
go func(done <-chan struct{}) {
defer conn.Close() // ✅ 当 done 关闭、函数 return 时触发
defer ch.Close()
for {
select {
case <-done:
log.Println("Consumer shutting down...")
return // ← 此处 return 触发 defer
default:
msgs, err := ch.Consume(...)
if err != nil {
log.Printf("Consume error: %v", err)
time.Sleep(1 * time.Second)
continue
}
for d := range msgs {
log.Printf("Received: %s", d.Body)
d.Ack(true)
}
}
}
}(quit) // quit := make(chan struct{})使用
带超时或条件终止的循环，确保函数存在明确退出点；
避免在长生存期 goroutine 中 defer 关键资源，改用 defer 在启动函数（如 start_consumer）中管理连接层资源，而 channel 级资源则由消费者 goroutine 自行按需关闭。
⚠️ 注意事项：
总结：defer 是函数级的延迟执行机制，不是 goroutine 级的生命周期钩子。理解其“依附于函数退出”的本质，是写出健壮并发代码的关键前提。