go程序中，当主goroutine提前退出时，其他goroutine会被强制终止，导致select无法接收到donechan信号——这是因缺乏同步机制引发的典型竞态问题。
在Go并发编程中，select语句本身是完全可靠的：只要通道可读（非nil、有数据或已关闭），且当前goroutine仍在运行，select就一定会响应对应的case。你遇到的“doneChan 根本原因并非select逻辑错误，而是主goroutine（通常是main函数）在子goroutine执行到下一次select之前已退出，整个程序终止，所有后台goroutine被强制杀死。
这是一个典型的生命周期不同步问题。观察你的复现场景：
- ✅ 两次写入 requestChan + 一次写入 doneChan：主goroutine等待时间足够长，子goroutine完成两次处理并进入第三次select，此时doneChan已就绪，成功退出；
- ❌ 仅一次写入 requestChan + 紧接着写入 doneChan：主goroutine发送完doneChan后立即结束，子goroutine可能还卡在第二次select的阻塞等待中，尚未开始检查doneChan，进程便已终结。
正确做法：显式同步goroutine生命周期
推荐使用 sync.WaitGroup 进行协作式等待：
package main
import (
"fmt"
"sync"
"time"
)
type Db_request struct {
request string
beehive string
}
func serveDatabase(requestChan <-chan Db_request, doneChan <-chan bool, wg *sync.WaitGroup) {
defer wg.Done() // 标记goroutine完成
for {
fmt.Printf("Waiting for select statement ...\n")
select {
case req := <-requestChan:
fmt.Printf("I got a request: %v\n", req)
case <-doneChan:
fmt.Printf("serveDatabase: Got closing signal. Stop serving.\n")
return
}
}
}
func main() {
requestChan := make(chan Db_request, 10)
doneChan := make(chan bool, 1) // 缓冲通道避免发送阻塞
var wg sync.WaitGroup
wg.Add(1)
go serveDatabase(requestChan, doneChan, &wg)
// 模拟业务请求
requestChan <- Db_request{request: "Login", beehive: "yaylaswiese"}
// requestChan <- Db_request{request: "Signup", beehive: "aziz nezir"}
fmt.Printf("Sending true to the doneChannel\n")
doneChan <- true
// 关键：等待子goroutine安全退出
wg.Wait()
fmt.Println("All goroutines finished. Exiting.")
}? 注意事项：WaitGroup 必须在启动goroutine前调用 Add(1)，并在goroutine内最后调用 Done()（建议用 defer）；doneChan 建议设为带缓冲通道（如 make(chan bool, 1)），避免主goroutine在子goroutine尚未进入select时因发送阻塞而卡住；切勿依赖 time.Sleep() 等不确定延迟来“等待”，这不可靠且违背Go并发设计哲学；若需更复杂的控制流（如超时退出、取消传播），应考虑 context.Context。
总结：Go中没有“后台线程”的概念，所有goroutine均依附于主程序生命周期。确保主goroutine通过同步原语（WaitGroup、channel、context）显式等待关键goroutine结束，是编写健壮并发程序的基石。
立即学习“go语言免费学习笔记（深入）”；
