Gin 不处理协程超时，需手动用 context.WithTimeout + select + 显式 goroutine 控制；中间件仅约束请求生命周期，无法管理 handler 内部并发调用。
直接说结论：Gin 本身不处理协程并发调用的超时，你得靠 context.WithTimeout + select + 显式启动 goroutine 来控制；中间件只能管住整个 HTTP 请求生命周期，管不了你在 handler 里 spawn 的多个下游调用。
为什么 Gin 默认不帮你管协程超时
Gin 的 c.Next() 和中间件链只串行调度请求处理流程，它对 handler 内部开多少 goroutine、怎么等结果完全无感知。你写 go callThirdParty()，Gin 不会自动给这个 goroutine 绑定超时上下文——这是你的责任。
- 常见错误现象：
time.Sleep(10 * time.Second)放在 goroutine 里，主 handler 却没设超时，导致整个 HTTP 请求卡满 10 秒，甚至触发 Nginx 的 60s timeout - 根本原因：Go 的 goroutine 是自治的，没有父 context 自动透传机制，必须手动把
c.Request.Context()传进去 - 性能影响：不加控制的并发调用容易耗尽连接池、打爆下游服务，或让本机 goroutine 数飙升（
runtime.GOMAXPROCS不是万能的）
用 context.WithTimeout 包裹每个外部调用
别在 handler 开头统一设一个超时然后扔进 goroutine —— 那个 context 只属于当前 goroutine，子 goroutine 拿不到。必须为每次远程调用单独构造带超时的 context。
- 正确做法：每个
http.Client.Do()或数据库查询前，都调用ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second) - 必须
defer cancel()，否则 context 泄漏，goroutine 无法被 GC 清理 - 如果调用链有嵌套（比如 A → B → C），上游 context 要一路透传，不能在中间层重新生成
- 示例片段：
func callUserSvc(ctx context.Context) (string, error) { req, _ := http.NewRequestWithContext(ctx, "GET", "https://user.api/users/123", nil) resp, err := http.DefaultClient.Do(req) if err != nil { return "", err } defer resp.Body.Close() // ... }
并发等待多个接口时用 select + channel 统一收口
当你同时调 callUserSvc、callOrderSvc、callPaySvc，不能用 sync.WaitGroup 硬等——它不响应超时。得用 channel + select 主动放弃。
- 每个调用启动 goroutine，并把结果或错误发到自己的 channel
- 主 goroutine 用
select监听所有 channel 和超时信号 - 一旦任一 channel 返回，立刻
c.Abort()或返回聚合结果；超时则全部 cancel 并返回 504 - 容易踩的坑：
- 忘记关闭 channel，导致
select永远阻塞 - channel 缓冲区为 0 且接收方未就绪，发送方 goroutine 卡死
- 没检查
ctx.Err() == context.DeadlineExceeded就直接返回，掩盖了真实错误
- 忘记关闭 channel，导致
别依赖 gin-contrib/timeout 这类第三方中间件
gin-contrib/timeout 只控制 handler 执行总时间，它内部也是用 context.WithTimeout 包一层，但无法穿透到你业务代码里的 goroutine。如果你的 handler 里开了 5 个 goroutine 去调下游，它只会在 handler 函数返回时才生效——而 handler 可能早就 return 了，那几个 goroutine 还在后台跑。
- 真实场景：handler 启动 goroutine 发请求，自己立即
return，中间件认为“执行完了”，但 goroutine 还在等响应 - 更危险的是：这些 goroutine 拿的是原始
c.Request.Context()，超时后不会自动取消，变成僵尸协程 - 所以，超时控制必须下沉到最外层调用点，不是加个中间件就万事大吉
真正难的不是写对那几行 context.WithTimeout，而是判断哪些调用必须加、加多长、cancel 是否真的触发了底层连接关闭——比如 http.Client 的 Transport 需要配 IdleConnTimeout，否则 DNS 缓存或 TCP 连接可能卡住，context cancel 也杀不掉。
