最常用且最易出错的上下文取消监听模式是 select + ctx.Done()；直接读 <-ctx.Done() 会无条件阻塞、无法响应其他逻辑，且无法获取取消原因，必须用 select 包裹并配合 ctx.Err() 判断错误类型。
select 读 ctx.Done() 是最常用但最容易写错的模式
Go 中监听上下文取消，90% 的场景都该用 select + ctx.Done()，但直接读 <ctx>.Done()</ctx> 通道（比如 <-ctx.Done()）会阻塞、无法配合其他逻辑，且忽略错误类型判断。真正安全的做法是始终用 select 套一层，并检查 ctx.Err()。
- 别写
val := <-ctx.Done()—— 这行代码一旦执行就卡死，除非上下文被取消，且你根本拿不到取消原因 - 必须用
select，且至少带一个default或另一个可操作的通道，否则就是无条件阻塞 -
ctx.Done()关闭后，<-ctx.Done()会立即返回零值，但此时要调用ctx.Err()才知道是context.Canceled还是context.DeadlineExceeded
标准写法：带超时/取消响应的 select 模式
典型服务循环中，既要处理业务通道，又要响应上下文结束。这时 select 必须同时监听 ctx.Done() 和其它通道，且退出前应清理资源。
for {
select {
case <-ctx.Done():
log.Println("context done:", ctx.Err())
return // 或执行 cleanup 后 return
case msg := <-dataCh:
process(msg)
case <-time.After(5 * time.Second):
log.Println("timeout tick")
}
}-
ctx.Done()放在select第一位不是必须的，但建议优先检查，避免业务逻辑被意外执行 - 如果
dataCh是无缓冲通道，且没有default，那select可能永远等下去——而ctx.Done()仍能及时中断它 - 不要在
case <-ctx.Done():里再调用<-ctx.Done()，这是常见冗余错误
为什么不能只用 <-ctx.Done() 而不用 select？
单独读 ctx.Done() 看似简洁，但在实际工程中几乎总是错的：它切断了并发协作能力，也掩盖了上下文状态细节。
- 函数内只写
<-ctx.Done()→ 整个 goroutine 卡住，无法响应任何其他信号（如关闭通知、重试指令） - 如果上下文是通过
context.WithTimeout创建的，<-ctx.Done()返回时你不知道是超时还是主动取消，而ctx.Err()能明确区分context.DeadlineExceeded和context.Canceled - 测试时很难 mock 或提前触发 ——
select结构允许你注入 fake channel，而裸读Done()只能等真实取消
容易被忽略的边界：Done 通道可能为 nil
某些自定义上下文（比如未用 context.WithCancel / WithTimeout 构造的空上下文）的 Done() 方法返回 nil。直接 <-ctx.Done() 会导致 panic: “invalid operation: <-nil”。
立即学习“go语言免费学习笔记（深入）”；
- 标准库
context.Background()和context.TODO()的Done()返回nil，这是合法且有意为之的设计 - 安全做法是：如果不确定上下文来源，先判空再
select，或统一用select+default避免阻塞 - 更稳妥的惯用写法：
select {
case <-ctx.Done():
return ctx.Err()
default:
}
// 后续逻辑可继续执行，且不阻塞真正麻烦的从来不是语法怎么写，而是忘记 ctx.Done() 可能为 nil、忽略 ctx.Err() 的具体类型、或者在 select 里漏掉清理路径。这些点不踩一遍坑，很难真信。
