Golang并发编程如何实现超时控制_Golang超时与取消实践

context.WithTimeout 本身不中断 goroutine，仅提供 Done() channel 和 Err()；需在关键路径（如 http 请求、数据库查询、循环）中显式监听 ctx.Done()，否则超时无效。

Go 中 context.WithTimeout 是最常用也最容易出错的超时方式

直接用 context.WithTimeout 启动 goroutine 本身不会自动中断正在运行的函数，它只提供一个可监听的 Done() channel 和配套的 Err()。真正起作用的是你是否在关键路径里检查这个 channel。

常见错误是：启用了 timeout context，但底层 HTTP 请求、数据库查询或自定义循环里完全没响应 ctx.Done()，导致 goroutine 实际卡住不退出。

• 必须在阻塞操作前或循环中显式 select ctx.Done()，例如：

  select { case <-time.After(5 * time.Second):     // 正常完成 case <-ctx.Done():     return ctx.Err() // 或做清理 }

• HTTP 客户端要传入带 timeout 的 context，不能只靠 http.Client.Timeout，后者不传播取消信号
• 数据库驱动（如 database/sql）支持 QueryContext、ExecContext 等方法，必须替换掉旧版无 context 的接口

用 time.AfterFunc 做超时是反模式，除非你不需要取消语义

time.AfterFunc 只能触发一次回调，无法与 goroutine 生命周期联动，也不能释放关联资源。它适合发告警、打日志这类“尽力而为”的场景，但不能替代 context 取消机制。

典型误用：

time.AfterFunc(3*time.Second, func() {     close(ch) // ch 可能已被读完或未初始化 })

这种写法竞态风险高，且无法区分是超时关闭还是业务主动关闭。

• 需要精确控制生命周期时，一律用 context.WithTimeout 或 context.WithCancel + 手动调用 cancel()
• time.AfterFunc 的 timer 不会自动 stop，如果 handler 没执行完就退出，timer 仍驻留直到触发，可能造成内存泄漏
• 若只是想延时执行某事（比如清理临时文件），且不依赖其他 goroutine 状态，AfterFunc 可用，但要加 defer timer.Stop() 防止重复触发

goroutine 泄漏往往源于忘记 select ctx.Done() 或未关闭 channel

超时控制失效最隐蔽的表现不是报错，而是 goroutine 数持续上涨。pprof 查到大量状态为 chan receive 或 select 的 goroutine，基本可以确定是 context 未被消费。

立即学习“go语言免费学习笔记（深入）”；

另一个高频坑是：向已关闭的 channel 发送数据，引发 panic；或向 nil channel 发送，导致永久阻塞。

• 所有接收方应统一用 select { case v := ，避免直接
• 发送方在 send 前先判断 ctx.Err() != nil，或用 select 包裹发送逻辑
• 不要在 defer 里关 channel，尤其当 channel 被多个 goroutine 共享时；优先让 sender 关闭，receiver 不负责关

第三方库对 context 支持程度差异大，务必查文档验证

像 redis/go-redis、elastic/go-elasticsearch 都要求显式传 ctx 到每个 API 调用；但有些老 SDK（比如部分云厂商的 Go SDK）只接受全局 client timeout，根本不接收 context 参数。

遇到这种库，只能在外层用 context.WithTimeout 包一层，并在 goroutine 内部用 select 监听超时，然后调用其提供的 Close() 或 Cancel() 方法（如果有）强行中断。

• 没有 cancel 接口的老库，超时后只能放弃该 goroutine，靠 runtime GC 回收，无法立即释放连接等系统资源
• 某些库的 context 仅控制请求发起阶段，不控制响应读取过程（如部分 HTTP 封装），这时需额外加 io.CopyContext 或手动分块读 + 检查 ctx.Done()
• 永远不要假设 “用了 context 就万事大吉”，每次集成新库都应写最小复现 case，用 runtime.NumGoroutine() 和 pprof 验证是否真能及时退出

实际并发超时控制最难的不是写对那几行 context.WithTimeout，而是确保整条调用链——从入口 goroutine、中间件、下游 SDK、到底层 syscall——每一环都尊重并传递 ctx。漏掉任意一环，超时就形同虚设。