select 遇到 nil channel 的 case 会永久阻塞该分支：nil channel 在 select 中永远不就绪，既不 panic 也不报错，仅静默失效；典型场景是动态停用 channel 时误设为 nil，导致 select 无法响应其他就绪 case。
select 会阻塞，但不是所有 case 都要等
select 的核心行为是：**只要有一个 case 就绪（channel 可读/可写），就立即执行对应分支；如果没有就绪的，且有 default，就走 default；否则就一直阻塞**。很多人误以为 select 会“轮询”所有 channel，其实它底层用的是 goroutine 的等待队列调度，不消耗 CPU。
常见错误现象：select 卡死、goroutine 泄漏、逻辑没触发——往往是因为忘了加 default，又恰好所有 channel 都没数据。
- 想非阻塞尝试收发？必须带
default分支 - 监听多个超时？用
time.After()或time.NewTimer()创建 channel，放进 select - 不能在
case中直接对 channel 赋值或重新声明，变量作用域仅限该分支
nil channel 在 select 中永远不就绪
这是最容易踩的坑：把一个值为 nil 的 channel 写进 select 的某个 case，那个 case 就永远无法触发——既不会 panic，也不会报错，只是静默失效。
典型场景：动态控制监听哪些 channel（比如连接断开后停掉对应读 channel），结果 channel 被置 nil 后，select 还在等它，却再也等不到。
- 避免手动设 channel =
nil，改用关闭 channel + 判断ok（val, ok := ） - 如果真要条件性跳过某个 case，用
if外包 select，而不是传nil - 调试时可加日志：在每个
case开头打点，确认是否进入——能快速定位是不是被nil卡住
select 中的 send 和 receive 不是原子操作组合
你不能指望 select 里两个 channel 的收发“同时成功”，它每次只选一个 case 执行。比如想“从 A 收一个，再往 B 发一个”，写成两个独立 case 是错的——它们互不影响，顺序也不保证。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
性能影响：频繁在 select 中混用无缓冲 channel 的 send/receive，容易引发 goroutine 挂起和调度延迟，尤其当目标 channel 没人接收/发送时。
- 需要配对操作？用单独 goroutine + channel 配合完成，别硬塞进一个 select
- 缓冲 channel 可缓解阻塞，但缓冲区大小要匹配业务节奏，
cap=1和cap=100对背压表现差异极大 - 不要在
case分支里启动新 goroutine 做耗时操作，否则可能拖慢整个 select 轮次
timeout 控制必须用 time.After() 或 timer，别手写循环
有人想“等 5 秒，超时就退出”，于是写个 for + time.Sleep，再检查 channel——这既不准（sleep 有误差），又浪费 goroutine。正确姿势是让 select 自己管超时。
注意：time.After() 返回的是单次 channel，不可重用；高频超时场景建议用 time.NewTimer() 并记得 timer.Reset() 和 timer.Stop()。
-
time.After(5 * time.Second)简洁，适合一次性等待 - 重复使用超时？必须
timer.Reset()，否则第二次会立刻触发（因为 timer 已过期） - 忘记
timer.Stop()会导致 timer 不释放，长期运行下内存泄漏
select 看似简单，真正难的是设计好 channel 的生命周期和关闭时机。一个没关的 channel，配上没 default 的 select，就是 goroutine 消失术的起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
