go 的 select 不支持 channel 优先级，多 case 同时就绪时伪随机选择；需用嵌套 select + default 实现逻辑优先级，不可依赖代码顺序；default 非超时机制，仅在无 case 就绪时立即执行。

select 本身不支持 channel 优先级，写在前面的 case 不会先执行——这是硬性限制，不是配置或技巧能绕过的。

多个 channel 同时就绪时，select 怎么选？

只要两个 case 都能立刻执行（比如两个带缓冲的 ch1 和 ch2 都有数据），select 就会伪随机挑一个，不按代码顺序、不按 channel 地址、也不按声明先后。这不是 bug，是 Go 运行时为防饥饿做的刻意设计。

• 测试中跑几次结果一样？多跑几十次，随机性马上暴露
• 不能靠把控制信号 ctrlCh 写在第一个 case 来“保证先处理”
• 如果业务真要优先级（比如必须先响应中断信号），就得用逻辑控制，而不是依赖 select 结构本身

想实现高优 channel 优先响应，该怎么做？

靠嵌套 select + default 拆开判断，而不是堆在一个 select 里混着写。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 外层 select 只监听高优 channel，加 default 防止阻塞
• default 分支里再套一个只监听低优 channel 的 select（可选 default）
• 别把 ch1（控制）和 ch2（数据）塞进同一个 select，否则优先级形同虚设
• 如果需要按内容排序（比如“紧急程度值最大”的任务优先），select 不是解法，该上 container/heap 做优先级队列

default 不是超时，别当计时器用

default 分支只是“所有 case 都不就绪时立刻执行”，它不启动任何计时器，也不等待——这是初学者最常踩的坑。

• 想等 1 秒超时？得用 case ，不是 <code>default
• default 里哪怕只写 ;，整个 select 也会变成零等待轮询，CPU 空转风险很高
• 没 default 的 select，所有 case 都不就绪就会永久阻塞——常见于 channel 被误设为 nil 或已关闭但还在读

nil channel 和已关闭 channel 在 select 中行为完全不同

把 channel 设为 nil 是最隐蔽的坑：它不会 panic，也不会报错，只是让对应 case 永远静默失效。

• case ：永远阻塞，且不干扰其他 <code>case
• case ：立即返回零值，<code>ok 为 false
• case nilChan ：永远阻塞
• case closedChan ：直接 panic
• 动态停用某个 channel？别赋 nil，改用关闭 + val, ok := 判断，或用 <code>if 外包 select

真正难的不是写对语法，而是理解 select 只做一次决策、不轮询、不排队——它不是事件循环，而是一次性多路分支选择。所有“我以为它会……”的预期，几乎都来自对这个前提的忽略。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！