select 必须至少包含一个 channel 操作，否则编译失败；空 select{} 报错“select statement with no cases”；default 用于非阻塞轮询，不等价于超时。
select 不是 switch，不能脱离 channel 单独存在；没 default 就阻塞，有 default 就轮询——但别误把 default 当超时。
select 必须带至少一个 channel 操作，否则编译失败
写 select {} 会直接触发编译错误：select statement with no cases。Go 要求每个 case 都得是真实的 channel 通信：要么 ，要么 <code>ch 。它不是流程控制语句，专为协调 goroutine 间通信而生。
- 想“等某个条件成立再继续”？那不是 select 的职责，用
for+if或 channel 信号更合适 - 把
http.Get或time.Sleep塞进case表达式里？函数会在 select 开始前就被执行，整个语句卡住不动 - nil channel 的
case永远不会就绪，可用于临时禁用某路（比如关闭重试通道）
default 分支不是超时，而是非阻塞轮询开关
加了 default，select 就不再等待，每次执行都立刻选一个就绪 case 或跳进 default。这适合状态检查、心跳探测，但容易引发 CPU 空转。
- 误把
default当作“3 秒没数据就退出”，结果逻辑永远走default，超时形同虚设 - 真要超时，必须用可接收的定时 channel，比如
- 高频循环中用
time.After会泄漏 timer，应改用time.NewTimer并在退出后调用timer.Stop() - 更稳妥的做法是统一走
context.WithTimeout，让取消信号自然流入所有支持 context 的 API
多个 case 同时就绪时，执行顺序完全随机
哪怕你把控制信号 channel 写在第一个 case，只要它和数据 channel 在同一时刻就绪，select 仍可能挑后者执行。这不是 bug，是 Go 故意为之的设计——避免隐式优先级导致饥饿或耦合。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 依赖书写顺序来保证“先处理退出信号再收数据”？大概率线上翻车
- 需要严格优先级，得拆成两层逻辑：先用带
default的 select 快速试探控制通道；没信号再进主 select 等数据 - 测试时多跑几次，观察输出变化，才能确认是否真被随机调度，别因单次结果固定就掉以轻心
- 缓存 channel（
make(chan int, 1)）会让本该阻塞的发送/接收突然就绪，进一步干扰预期行为
超时控制别只盯 time.After，注意资源生命周期
time.After 方便，但返回的 channel 只能读一次，且底层 timer 对象若长期不触发，无法被 GC 回收。循环场景下积累多了就是内存泄漏。
- 一次性初始化逻辑（如服务启动）可用
time.After，简单直接 - 长连接心跳、重试循环等高频场景，必须用
timer := time.NewTimer(d)，并在 select 退出后立刻执行timer.Stop() - 手动管理 timer 容易漏掉
Stop，尤其函数提前 return 时；用context.WithTimeout能自动清理底层资源 - 注意：
context.CancelFunc必须显式调用，否则 timer 和关联 goroutine 不释放
最常被忽略的点是：select 的随机性不是调试时的偶然现象，而是运行时确定行为；而 timer 泄漏也不会立刻报错，往往压测几天后才暴露。写的时候多想半秒，比上线后查三天日志强。
