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