select {} 会 panic 是因为其让 goroutine 永久阻塞且无任何 channel 可就绪，触发死锁错误；它不是 switch 语法糖，而是专为 channel 通信设计的并发原语。
select 语句不能脱离 channel 单独存在，写 select {} 会运行时 panic 死锁；它不是 switch 的语法糖，而是专为 channel 通信设计的并发原语。
为什么 select {} 会 panic？
空 select 不是“什么都不做”，而是让当前 goroutine 永久阻塞、等待某个 channel 就绪——但既然没写任何 case ch，就永远等不到。Go 运行时检测到所有 goroutine 都在阻塞且无其他活跃协程，直接触发 fatal error: all goroutines are asleep - deadlock!。
- 常见误用：想“挂起主线程”，却写了
select {}而不是启动 worker 后再阻塞 - 正确做法：确保至少有一个 goroutine 在往你监听的 channel 发数据，或加
default分支实现非阻塞轮询 - 替代方案：
select {}只应在明确有其他 goroutine 活跃时使用，比如主协程等待信号退出
default 分支不是“兜底”，而是唯一打破阻塞的开关
当所有 case 都无法立即执行（比如接收空 channel、发送满 buffer），default 是唯一能被选中的分支。它让 select 变成非阻塞操作——但代价是可能高频触发，导致 CPU 空转。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 适用场景：心跳检测、状态轮询、超时重试前的快速试探
- 慎用场景：放在 tight loop 里又不加
time.Sleep或time.Tick，会吃满一个核 - 注意：
default和case是互斥的——只要任一case就绪，default就不会执行
多个 case 同时就绪时，选哪个不靠顺序，靠伪随机
Go 运行时不保证 case 执行顺序。哪怕 ch1 总是先发数据、ch2 总是后发，只要两者在 select 求值完成瞬间都已就绪，执行哪个完全随机。这不是 bug，是刻意设计，避免调度偏斜和饥饿。
- 别依赖书写顺序控制优先级（例如把
ctx.Done()写在后面 ≠ 优先级低） - 真要优先响应取消信号？拆成两个
select：先单独检查ctx.Done()，再处理业务 channel - 调试时多跑几次，观察输出是否变化——固定输出≠顺序保障，可能是巧合
函数调用写在 case 里会提前求值，可能卡住整个 select
select 开始前，会先对所有 case 中的 channel 表达式和待发送值求值。如果其中包含阻塞调用（如 http.Get()、time.Sleep()），整个语句就卡在求值阶段，根本进不了等待逻辑。
- 错误写法：
case data := —— 如果 <code>getData()是个耗时函数，它会在select启动前就执行并阻塞 - 正确写法：把副作用操作提到
select外，只在case里做纯 channel 操作 - 特别注意：nil channel 的
case永远不会就绪，可用于临时禁用某路（比如关闭某个数据源）
最易被忽略的点是：每个 case 必须是一个原子 channel 操作，不能混入赋值、条件判断或函数调用；而 select 的随机性不是缺陷，是并发公平性的基石——接受它，比试图绕过它更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
