Context取消机制本质是监听done channel，而非直接终止函数；需在关键路径主动select ctx.Done()以响应取消，否则cancel()调用无效。
Context取消机制本质是监听 done channel
Context 的取消不是直接终止函数，而是通过 ctx.Done() 返回一个只读 channel，让函数自己感知并退出。只要函数内部没主动监听 ctx.Done()，传入再“优雅”的 Context 也毫无作用。
常见错误是以为调用 cancel() 就能立刻停住 goroutine——实际上它只是关闭 ctx.Done()，后续行为完全取决于你是否在关键路径上 select 这个 channel。
- 必须在可能阻塞或耗时操作前/中检查
ctx.Done()，比如网络请求、time.Sleep、channel 操作 - 不要在 for 循环里漏掉
select { case ，否则循环会一直跑下去 - 如果函数调用了其他库（如
http.Client.Do()），要确认该库是否原生支持 Context；否则需手动包装
如何在自定义函数中正确接入 Context 取消
写一个支持取消的函数，核心就三点：接收 Context、监听 ctx.Done()、及时返回错误。下面是一个典型示例：
func fetchWithTimeout(ctx context.Context, url string) ([]byte, error) {
resp, err := http.DefaultClient.Do(http.NewRequestWithContext(ctx, "GET", url, nil))
if err != nil {
return nil, err
}
defer resp.Body.Close()
<pre class="brush:php;toolbar:false;">// 读取响应体时也要可取消
select {
case <-ctx.Done():
return nil, ctx.Err()
default:
}
body, err := io.ReadAll(resp.Body)
if err != nil {
return nil, err
}
return body, nil}
立即学习“go语言免费学习笔记（深入）”；
注意：io.ReadAll 本身不响应 Context，所以要在读之前加一次 select 判断；更稳妥的做法是用 http.Response.Body.Read 分块读，并在每次读前检查 ctx.Done()。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 所有阻塞点（I/O、sleep、channel recv/send）前后都应插入 Context 检查
- 返回错误时统一用
ctx.Err()，它会返回context.Canceled或context.DeadlineExceeded - 避免在 defer 中依赖已取消的 Context，比如 defer 关闭一个需要 Context 的资源时，先判断
ctx.Err() == nil
cancel() 调用后为什么 goroutine 还没退出？
最常见原因是：goroutine 正卡在系统调用（如 socket read、syscall.Write）或 runtime 内部调度点，无法立即响应 ctx.Done()。Go 不提供抢占式取消，一切依赖协作式退出。
例如：time.Sleep(10 * time.Second) 在中间被 cancel，它不会提前返回；必须改用 select { case 。
- 标准库中部分函数（如
net.Conn.SetDeadline）可配合 Context 实现近似即时中断，但需手动设置 - 数据库驱动（如
database/sql）从 Go 1.8+ 开始支持 Context，但旧版本或某些 driver 仍忽略 - 第三方库若未声明支持 Context，不能假设它会响应取消；必要时需加超时封装或信号级兜底
Context.Value 和取消无关，别混用
context.WithValue() 是为传递请求范围的元数据（如用户 ID、trace ID），不是控制流工具。有人误把取消逻辑塞进 Value 里，结果发现 ctx.Value("cancel") 没法触发任何行为——因为 Value 不广播、不通知、不关闭 channel。
真正驱动取消的只有 ctx.Done() 和配套的 cancel() 函数。Value 仅用于只读上下文信息，且应尽量少用（类型安全差、易滥用）。
- 取消逻辑永远走
select监听ctx.Done()，不是靠检查某个 Value 值 - Value 的 key 应该是自定义 unexported 类型，避免字符串冲突；比如
type key string; var userIDKey key = "user_id" - 如果函数既要读 Value 又要响应取消，两个需求独立处理：一个从
ctx.Value()取值，一个用ctx.Done()控制生命周期
实际项目里最常被忽略的是：取消不是“设个 Context 就完事”，而是每一层调用都要显式检查、传播和响应。哪怕只漏掉一个 select，整个调用链就卡死。
