context是Go中管理并发生命周期的核心工具，用于超时控制、主动取消和传递请求值；它通过WithTimeout和WithCancel创建可取消的子context，需正确传递并及时调用cancel，避免内存泄漏。
在 Go 中，context 是管理并发操作生命周期的核心工具，尤其适合控制超时、主动取消、传递请求范围的值。它不负责启动或等待 goroutine，而是为多个 goroutine 提供统一的“信号通道”——一旦父 context 被取消或超时，所有派生出的子 context 都能感知并响应。
用 context.WithTimeout 控制操作最长执行时间
当你需要限制某段逻辑（比如 HTTP 请求、数据库查询、外部 API 调用）最多运行多久时，WithTimeout 最常用。它返回一个带截止时间的子 context 和一个 cancel 函数（必须调用，避免内存泄漏）。
示例：等待一个可能卡住的 goroutine，最多 2 秒
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel() // 关键：及时释放资源ch := make(chan string, 1) go func() { time.Sleep(3 * time.Second) // 模拟耗时操作 ch <- "done" }()
select { case result := <-ch: fmt.Println("成功:", result) case <-ctx.Done(): fmt.Println("超时:", ctx.Err()) // 输出: context deadline exceeded }
注意：ctx.Done() 是一个只读 channel，当超时触发时会关闭，select 可立即捕获。
立即学习“go语言免费学习笔记（深入）”；
用 context.WithCancel 主动终止正在运行的操作
当用户中断请求、服务准备下线、或上游已放弃时，需主动通知下游停止工作。此时用 WithCancel 创建可手动触发的 context。
- 调用
cancel()后，ctx.Done()立即关闭，所有监听它的 goroutine 可退出 - 适合组合多个条件取消：比如同时监听超时 + 用户点击取消按钮
- 子 context 会继承父 context 的取消信号，形成级联取消链
常见模式：HTTP handler 中监听客户端断开
func handler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context() // HTTP server 自动提供可取消 context
done := ctx.Done()
go func() {
select {
case <-done:
log.Println("客户端断开或请求取消")
// 清理资源、关闭连接等
}
}()
// 正常处理逻辑...}
在函数调用链中正确传递 context
context 应作为第一个参数传入，且命名统一为 ctx。不要把它塞进结构体或全局变量——这会让依赖关系隐晦、测试困难、取消逻辑失效。
- 所有可能阻塞或耗时的函数（如
http.Do,db.QueryContext,time.Sleep）都支持接收 context - 自定义函数也应接受
ctx context.Context并在关键点检查ctx.Err()或监听ctx.Done() - 若需附加请求级数据（如 trace ID、用户身份），用
context.WithValue，但仅限不可变、低频、明确用途的键值对
反例：把 context 存在 struct 里长期持有；正例：
func fetchUser(ctx context.Context, userID int) (*User, error) {
select {
case <-ctx.Done():
return nil, ctx.Err()
default:
}
// 实际逻辑，过程中可多次检查 ctx.Err()
return db.GetUser(ctx, userID) // 假设 db 方法支持 context
}
避免常见陷阱
context 不是万能胶，误用会导致难以调试的问题：
-
不重复 cancel：同一个
cancel函数调用多次无害，但没必要；更危险的是漏调——导致 goroutine 泄漏 - 不跨 goroutine 复用 background 或 todo context：它们没有取消能力，无法响应外部信号
-
不在循环里反复创建新 context：例如 for-select 中每次新建
WithTimeout，可能生成大量垃圾且逻辑混乱 - 不把 context 当作错误处理替代品：context 取消是协作式退出，不是 panic 或 error return 的替代方案
记住：context 的核心是“传播取消信号”，不是执行取消动作本身——每个参与方都要主动响应。
