Go selectdefault 怎么处理取消信号

很多人第一次给 Go 的 select 加 default，是想让 worker “别卡住”。但取消信号也放在同一个 select 里时，真正需要先分清的是：default 只代表“当前没有可立即完成的通信”，并不代表“没有取消”。处理取消要监听 ctx.Done()；否则循环可能在取消后继续空转。

官方地址：https://go.dev/

一、先分清 default 和取消信号的职责

Go 规范把 select 定义为从可进行的发送或接收中选择一个；如果没有通信可以进行，有 default 就立刻执行它，没有 default 才会阻塞等待。也就是说，下面的 default 是“现在没拿到任务”的结果，不是取消状态：

select {
case job := 

取消是另一条通信：context.WithCancel 返回的上下文在取消函数被调用，或父上下文取消时关闭 Done()。因此，代码要把“停止工作”的语义写在 case 中，而不是塞进 default。

二、把 ctx.Done() 作为退出分支

消费任务时，最小可靠写法是不加 default，让 goroutine 在“等任务”和“等取消”之间阻塞等待：

func consume(ctx context.Context, jobs 

这里的 ctx.Err() 通常会告诉调用方是超时还是主动取消。cancel 仍应由创建上下文的一方及时调用，以释放相关资源；worker 不需要等待取消函数返回后再做第二套轮询。

三、需要非阻塞读取时，default 只做探测

有些场景确实要先看一眼是否已经取消，或尝试拿一条可选消息。这时可以使用 default，但必须明确它是“探测”，不能把它写成没有数据就马上重试的无限循环：

func tryReceive(ctx context.Context, jobs 

如果业务要求持续轮询，给循环加 time.Ticker、退避或其他明确节奏；单纯的 for { select { ... default: } } 会在无任务时反复执行，既看不到取消的业务处理，也容易占满 CPU。多数 worker 不需要轮询，直接使用上一节的阻塞式 select 更简单。

四、检查关闭通道和取消同时到达的边界

关闭的 channel 的接收操作会立即就绪，并返回元素类型的零值和 ok=false。如果同时有多个 case 就绪，Go 会从中伪随机选择一个，所以不要假设“取消一定先于最后一条任务被处理”。可以用下面的清单检查实现：

若“取消后绝不能再处理任务”是硬要求，可以在取得任务后再检查一次 ctx.Err()，并把已经取出的任务放回或标记为未提交；这属于业务事务策略，不是 default 能自动保证的顺序。测试时至少覆盖：无任务等待、主动 cancel、父 context 取消、jobs 关闭、取消与数据同时就绪，以及重复调用 cancel。

相关问题

select 里有 default 就一定不会阻塞吗？

对这一次 select 而言是的：如果其他通信都未就绪，就立即执行 default。但 default 所在的外层循环仍可能持续占用 CPU。

能把 default 当成取消分支吗？

不能。default 没有携带取消原因，也不知道上下文是否已结束；取消应通过 ctx.Done() 和 ctx.Err() 传递。

为什么关闭的 jobs 会反复读到零值？

因为关闭后的接收会继续立即就绪。使用双值接收并检查 ok=false，退出循环即可。