Go中实现任务超时取消需用context.WithTimeout创建子上下文并defer调用cancel，监听ctx.Done()及时退出；context取消链为单向父子继承，子取消不影响父；I/O操作须用原生支持Context的方法或手动检查Done()。
在 Go 中实现任务超时取消，核心是使用 context 包提供的 WithTimeout 或 WithDeadline，配合可取消的上下文（context.Context）和监听 ctx.Done() 通道来主动退出长时间运行的操作。
超时取消的基本写法
最常用的方式是用 context.WithTimeout 创建带超时的子上下文，然后把该上下文传给可能阻塞的函数（如 HTTP 请求、数据库查询、goroutine 协作等）：
- 调用
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，返回一个带超时的上下文和一个取消函数 - 务必在函数结束前调用
cancel()（通常用defer cancel()），避免上下文泄漏 - 在任务中持续检查
ctx.Err()或监听，一旦收到信号就立即停止当前工作
例如启动一个可能耗时的 goroutine：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel()go func() { select { case <-time.After(5 * time.Second): fmt.Println("任务完成") case <-ctx.Done(): fmt.Println("任务被取消：", ctx.Err()) // context deadline exceeded } }()
context 取消链的本质
Go 的 context 不是“广播”机制，而是单向、父子继承的取消链。子上下文只能由其父上下文或自身超时/取消触发 Done() 通道关闭，不能反向影响父级。
立即学习“go语言免费学习笔记（深入）”；
- 每个
WithCancel/WithTimeout/WithDeadline都会创建新节点，形成树状结构 - 父上下文取消 → 所有直接子上下文同步取消；但子上下文取消 ≠ 父上下文取消
- 多个子上下文之间互不影响，各自独立管理生命周期
这种设计保证了职责清晰：调用方控制超时，被调用方只响应取消，不越权干预上游逻辑。
在 I/O 操作中正确集成取消
不是所有操作都原生支持 context，需注意适配方式：
-
net/http.Client：直接传入带 timeout 的 context 到
Do(req.WithContext(ctx))，底层自动响应取消 -
database/sql：用
db.QueryContext(ctx, ...)等带 Context 的方法，驱动会尝试中断执行中的查询 -
自定义阻塞操作（如轮询、sleep、channel 等）：必须手动检查
ctx.Done()，不可仅依赖外部中断
错误示范：time.Sleep(10 * time.Second) 不响应 context；正确做法是用 select { case 。
常见陷阱与建议
实际使用中容易忽略几个关键点：
- 忘记调用
cancel()→ 导致 goroutine 和 timer 泄漏，尤其在 error 提前返回时 - 把同一个 context 多次传给不同长期任务 → 任一任务取消都会波及其它，应按需创建独立子 context
- 在循环中频繁创建新 context → 增加调度开销，应复用或提前构造
- 误以为
ctx.Value()能传递取消能力 → 它只传数据，取消靠Done()通道
基本原则：谁创建 context，谁负责 cancel；谁接收 context，谁负责监听 Done 并及时退出。
基本上就这些。context 取消链不复杂，但容易忽略细节。只要记住“创建即负责、传递即响应”，就能写出健壮的超时控制逻辑。
