如何使用Golang context控制请求超时_Golang context超时与取消策略

context 通过信号传递实现优雅超时与取消，不直接终止 Goroutine；需用 WithTimeout 创建并透传上下文，调用 cancel 防泄漏，I/O 操作须检查 ctx.Err() 并手动监听取消做清理。

在 Go 中，context 是控制请求生命周期（尤其是超时与取消）的核心机制。它不直接“杀死” Goroutine，而是通过传递信号，让被调用方主动退出，从而实现优雅的超时控制和资源清理。

使用 context.WithTimeout 控制 HTTP 请求超时

HTTP 客户端默认没有超时限制，容易导致连接堆积或长时间阻塞。应显式传入带超时的 context.Context：

• 创建超时上下文：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
• 务必在使用后调用 cancel()，避免内存泄漏（可用 defer cancel()）
• 将 ctx 传给 http.NewRequestWithContext(ctx, ...)，而非旧版 NewRequest
• HTTP 客户端会自动监听该上下文：一旦超时，请求立即中止，底层连接会被关闭

嵌套调用中传递并延续超时信号

服务 A 调用服务 B，B 又调用数据库或下游服务时，需把原始超时上下文向下透传，确保整条链路受统一时限约束：

• 不要在中间层新建独立超时（如 WithTimeout(ctx, 2*time.Second)），除非有明确的子任务 SLA
• 若需为某子操作单独设限，可用 context.WithTimeout(parentCtx, ...)，但记得仍从父 ctx 派生，保持取消传播
• 所有 I/O 操作（DB 查询、RPC、文件读写）都应接收 ctx 参数，并在内部检查 ctx.Err() != nil 提前返回

手动监听取消信号做清理

不是所有操作都原生支持 context（比如自定义阻塞逻辑、长轮询、第三方库无 ctx 接口）。这时需主动监听：

• 用 select { case 等待取消通知
• 在 case 分支中释放资源：关闭文件、断开连接、停止 goroutine
• 注意：ctx.Err() 在取消后才非 nil，且只返回一次；多次调用安全，但不能用来“重置”上下文

避免常见陷阱

几个高频出错点：

• 不要把 context 当作数据容器存业务参数 —— 它专为取消/超时设计，传参请用函数参数或结构体
• 不要忘记调用 cancel() —— 即使超时已触发，显式 cancel 仍能提早释放关联的 timer 和 goroutine
• 不要用 background 或 todo context 做实际请求 —— 它们无法被取消，会使超时逻辑失效
• 测试超时场景时，可用 context.WithCancel 手动触发取消，比等真实超时更可靠

基本上就这些。context 超时不是魔法，关键在于每一层都尊重并传递信号，配合及时的资源清理，才能真正实现可控、可测、可维护的请求生命周期管理。