Select Case 是一种多分支条件控制语句，用于根据表达式值匹配多个Case分支并执行对应语句；语法为 Select Case testexpression，后接若干 Case expressionlist [statements] 和可选 Case Else，匹配首个成功分支后即执行并跳出，支持数值、字符串、范围（To）、比较（Is）及逗号分隔的多值匹配。
为什么 select { case
因为 done channel 没被关闭，或者关闭得太晚——更常见的是：主 goroutine 提前退出了，其他 goroutine 还没来得及监听到信号就被系统强制终止。Go 不会等你“慢慢退出”，它只认当前 goroutine 是否还在运行。
-
done必须由**唯一可信方**（通常是主函数或 manager goroutine）负责关闭，且要在所有依赖它的 goroutine 启动之后、退出之前完成 - 不要在多个 goroutine 里重复
close(done)，会 panic - 如果用
context.WithCancel()，记得传入 context 并监听ctx.Done()，而不是自己造donechannel —— context 自带同步保障和层级传播能力 - 检查是否漏掉了
select外层的循环结构：单次select执行完就结束了，真正需要“持续监听退出信号”的是for循环 +select
for-select 中如何避免忙等待又不卡死？
别用 time.After(1 * time.Millisecond) 做轮询，那不是优雅退出，是伪装成并发的 busy-waiting，CPU 白烧，延迟还不可控。
- 正确姿势是：把
done放进select的一个case，其余逻辑走default或其他 channel 分支 - 如果循环体本身执行极快（比如状态检测、计数器更新），直接
for { select { case - 如果
doWork()可能阻塞（如网络调用），必须把它包进另一个 goroutine，或改用带超时的 context 控制 - 永远不要在
default分支里加time.Sleep来“降频”——这会让退出延迟最多达 sleep 时长，违背“优雅”的本意
channel 关闭后，接收端怎么安全退出？
关闭 done channel 本身不会让 立即就绪；它只是让后续接收操作返回零值+<code>ok==false。但 select 里的接收操作一旦就绪，就会立刻触发对应分支。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对无缓冲
donechannel，关闭后在 <code>select中**立即就绪**，无需额外判断ok - 若用了带缓冲的
done（不推荐），关闭后仍可能有残留值，需配合value, ok := 判断 - 错误写法：
if done == nil { return }——done是变量，不是 channel 状态，关不关闭跟它是不是 nil 无关 - 最简可靠模式：
for {<br> select {<br> case <-done:<br> return<br> default:<br> // 工作逻辑<br> }<br>}
goroutine 泄漏常出现在哪个环节？
不是没写 case ，而是写了却没生效——比如 goroutine 启动后，<code>done 才创建；或者 done 被关闭了，但该 goroutine 正卡在另一个没设超时的 channel 接收上。
立即学习“go语言免费学习笔记（深入）”；
- 启动 goroutine 前，确保
done已存在且可被引用（不能在 goroutine 内部make(chan struct{})） - 所有阻塞式 channel 操作（尤其是外部服务调用）都应配超时，要么用
time.After，要么用context.WithTimeout - 避免在
select中同时监听多个无保护 channel：其中一个永久阻塞，整个 goroutine 就再也收不到done - 用
go tool trace或pprof查未退出 goroutine 时，重点看它们停在哪一行或 <code>select上
真正的难点不在语法，而在信号传递的时机与范围——done 必须比它要控制的所有 goroutine “活得更久”，又不能“活得太久”导致资源滞留。这中间没有魔法，只有清晰的责任边界和一次到位的关闭动作。
