go select 语句卡住是因为其默认阻塞设计：当所有 case 的 channel 均不可读/不可写时，goroutine 挂起；常见于仅写 case 而未加 default 或超时处理。
Go select 语句为什么卡住不执行？
select 默认是阻塞的，只要所有 case 的 channel 都不可读/不可写，整个 goroutine 就会挂起——不是 bug，是设计如此。常见于只写了 case 却忘了初始化或关闭 channel，或者多个 channel 都没数据可收。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认每个
case对应的 channel 已正确创建、有 goroutine 往里发数据，或已关闭（关闭后可读出零值） - 需要非阻塞时，必须加
default分支，哪怕只写default: time.Sleep(time.Millisecond) - 调试时可在每个
case前加日志，比如log.Println("about to read from ch1")，快速定位卡在哪条路
多个 case 同时就绪时，Go select 怎么选？
Go runtime 会**随机选择一个就绪的 case**，不是按代码顺序，也不是按 channel 优先级。这是为了防止隐式依赖顺序导致的竞态或饥饿问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别假设
case ch1 一定比 <code>case 先执行——即使 ch2 早有数据，runtime 仍可能挑 ch1 - 如果业务逻辑强依赖处理顺序（比如“必须先响应控制信号再处理数据”），得用额外同步机制（如
sync.Mutex或拆成两个独立 select） - 想验证随机性？写个循环跑 100 次
select，打印选中分支，基本看不到固定模式
select 里能用变量 channel 吗？要注意什么？
可以，但 channel 变量在 select 开始执行那一刻就被“快照”了。后续改它指向别的 channel，对当前正在运行的 select 没影响。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免在 select 外部反复赋值 channel 变量，比如
ch = chList[i]然后进 select——容易误以为每次 case 都在用新 channel - 如果要动态切换 channel，应该用 slice + for 循环配合多个 select，或封装成函数传入 channel 参数
- nil channel 在 select 中永远阻塞：把
ch设为nil是一种“禁用该分支”的惯用法，但得确保你真想要这个效果
超时和取消场景下，select 怎么写才可靠？
time.After 和 context.WithTimeout 是主流方案，但直接用 time.After 有内存泄漏风险（定时器对象不会被 GC，直到触发），而 context 更适合传递取消信号。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 短时超时（time.After(500 * time.Millisecond) 简单直接；长时或需主动取消，必须用
ctx.Done() - 别在 select 外部调
cancel()后还往 channel 发数据——可能引发 panic 或 goroutine 泄漏 - 组合多个 channel 时，把
ctx.Done()放第一个case不代表它优先级高，只是代码习惯；真正决定权仍在 runtime 随机选择
select 的随机性和阻塞性是它的骨架，不是缺陷。很多人试图绕过它去“控制顺序”，结果掉进更难 debug 的竞态里。真正该花时间琢磨的，是 channel 的生命周期管理——谁关、何时关、关完怎么清理关联 goroutine。
