17370845950

Go 语言处理并发超时应使用 context.WithTimeout/WithDeadline 配合 ctx.Done() 监听，所有 goroutine 需主动响应取消信号，调用方须检查 err 并在循环中每次迭代监听 ctx.Done()。

Go 语言中处理并发超时，核心是用 context.Context 配合 context.WithTimeout 或 context.WithDeadline，而不是靠手动计时或轮询。关键在于让所有参与的 goroutine 都能感知并响应取消信号。

用 context.WithTimeout 包裹耗时操作

这是最常见也最推荐的方式：在发起请求、启动 goroutine 或调用阻塞函数前，创建带超时的 context，并将其传入支持 context 的函数（如 http.Client.Do、sql.DB.QueryContext、自定义函数）。

• 超时后，context 自动触发 Done() 通道关闭，关联的 Err() 返回 context.DeadlineExceeded
• 务必检查返回的 err，尤其是调用方自己实现的函数，需主动监听 ctx.Done() 并提前退出
• 示例：ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second); defer cancel()

让自定义 goroutine 响应 context 取消

如果你启用了自己的 goroutine（比如轮询、长连接、计算任务），不能只依赖外部 context 传递——必须在 goroutine 内部显式监听 ctx.Done()。

• 用 select 语句同时等待业务逻辑完成和 ctx.Done()
• 收到取消信号后，应尽快清理资源（关闭 channel、释放锁、断开连接）并 return
• 避免在循环中忽略 context 检查，尤其在 for-select 结构里，每次迭代都应包含 case

超时嵌套与父子 context 的正确传递

多个层级调用时，不要重复创建新 timeout context；而应把上游传入的 context 直接向下传递，或基于它派生子 context（如用 context.WithValue 加参数，但不改 deadline）。

• 错误做法：每个函数都调 WithTimeout，导致超时时间被层层叠加或覆盖
• 正确做法：入口处设总超时，内部调用统一用该 ctx；若某子任务需更短时限，可基于原 ctx 派生新 timeout ctx（注意调 cancel）
• HTTP handler 中，r.Context() 已携带请求生命周期 context，应优先复用它

注意 select + time.After 的陷阱

别用 time.After 替代 context 超时——它无法被主动取消，容易造成 goroutine 泄漏。

• time.After(5 * time.Second) 会启动一个后台 goroutine，即使你不再读取它，也会等满 5 秒才释放
• 而 context.WithTimeout 的 cancel 函数可立即中断等待，且资源可控
• 如果只是简单延时，且确定不会提前取消，time.Sleep 更轻量；但涉及并发协调，必须用 context

基本上就这些。context 超时不是“加个参数就完事”，重点是整条调用链都尊重并传播取消信号。写代码时多问一句：“这个 goroutine 能否在 ctx.Done() 后干净退出？”——答案为否，就得补上监听逻辑。