Go中context取消未触发terminate？为何需用select处理？

问题重现 #

测试代码如下：

package main

import (
  "fmt"
  "context"
)

func main() {
  ctx := context.Background()

  do(ctx)
}

func do(ctx context.Context) {
  ctx, ctxCancel := context.WithCancel(ctx)

  resultCh := make(chan string)

  go terminate(ctx, resultCh)

  resultCh <- "value1"
  resultCh <- "value2"

  fmt.Println("pre cancel")

  ctxCancel()

  fmt.Println("post cancel")
}

func terminate(ctx context.Context, ch <-chan string) {
  for {
    select {
    case <-ctx.Done():
      fmt.Println("terminate")
      return
    case result := <-ch:
      fmt.Println(result)
    }
  }
}

调用ctxCancel()后，terminate函数未输出预期的"terminate"日志，实际输出缺少该内容；预期输出应为：

value1
value2
pre cancel
terminate
post cancel

在ctxCancel()后添加time.Sleep(100 * time.Millisecond)，输出符合预期：

ctxCancel()
time.Sleep(100 * time.Millisecond) // 新增代码

原因分析 #

核心原因是main goroutine退出导致程序直接终止：

• 调用ctxCancel()后，do函数立刻执行完fmt.Println("post cancel")并返回，main goroutine随即执行完毕。
• Go程序的规则是：只要main goroutine结束，整个进程会立刻退出，所有未执行完的子goroutine都会被强制终止，根本没机会处理ctx.Done()的信号。
• 添加time.Sleep后，main goroutine暂停一段时间，给子goroutine留出了处理ctx.Done()事件的时间，因此能输出"terminate"。

需掌握的核心知识点 #

• 程序退出规则：main goroutine是程序的入口，它的结束意味着整个程序终止，不管其他goroutine是否完成任务。
• Context取消的异步性：调用cancel()只是关闭ctx.Done()通道发送取消通知，不会阻塞等待目标goroutine处理完成。若需要等待goroutine退出，需额外使用sync.WaitGroup这类同步机制。
• 无缓冲通道特性：示例中的resultCh是无缓冲通道，resultCh <- "value1"会阻塞直到子goroutine接收数据，这也是前两个值能正常输出的原因；但取消信号发送后，main goroutine无等待逻辑，直接结束。

为什么要在select中等待？ #

select的作用是让goroutine同时监听多个通道事件：

• 如果不用select，terminate函数会一直阻塞在<-ch的接收操作上，即使ctx被取消，也无法响应退出信号，会导致goroutine泄漏。
• 通过select，goroutine可以在等待业务数据的同时，实时监听取消信号，一旦收到通知就能立即退出，保证资源及时释放，避免无效阻塞。

内容的提问来源于stack exchange，提问作者nrs3