context.WithTimeout 是 Go 并发中超时控制最可靠的方式，它提供可取消、可传递、可组合的语义，需在每次阻塞操作前检查 ctx.Err() 并传入下游函数。
Go 中 context.WithTimeout 是最可靠的选择
在 Go 并发中，超时控制不能依赖 time.After 单独阻塞，因为无法主动取消底层 goroutine；context.WithTimeout 提供可取消、可传递、可组合的语义，是官方推荐且生产环境唯一稳妥的方式。
它返回一个 context.Context 和 cancel 函数：超时自动触发 Done() 通道关闭，调用 cancel() 可提前释放资源。关键点在于——必须在所有可能阻塞的位置检查 ctx.Err()，否则超时形同虚设。
- 不要只在函数入口处检查
ctx.Err()，而要在每次 I/O、channel 操作、循环迭代前检查 - 传入
ctx到下游函数（如http.NewRequestWithContext、db.QueryContext），让超时穿透整条调用链 -
WithTimeout底层基于timer，启动开销小，但频繁创建短超时 context 仍需注意 GC 压力
别用 select + time.After 直接替代 context
常见错误写法：
select {
case result := <-ch:
return result
case <-time.After(5 * time.Second):
return errors.New("timeout")
}这种模式看似简洁，但存在两个硬伤：一是 time.After 创建的 timer 不会因 select 结束而停止，持续到超时时间结束，造成泄漏；二是无法主动取消，无法响应上游中断信号。
更隐蔽的问题是：如果 ch 永不就绪，time.After 的 goroutine 就一直挂着，大量并发请求下内存和 goroutine 数量会线性增长。
- 若坚持用
select，应配合time.NewTimer并显式Stop()，但依然不如context统一管理 - HTTP 客户端、数据库驱动等标准库组件均只接受
context.Context，不用 context 就意味着放弃集成能力 - 测试时难以模拟超时场景——
time.After无法被 mock，而context.WithDeadline可用testhelper类工具控制
context.WithCancel 和 WithTimeout 的本质区别
WithTimeout 本质是 WithDeadline 的封装，而 WithDeadline 内部基于系统单调时钟计算截止时间；WithCancel 则完全依赖手动调用 cancel()。两者都生成带 Done() 通道的 context，但触发机制不同：
-
WithTimeout(ctx, d)：从调用时刻起计时d，即使中间有调度延迟或 GC STW，也严格按 wall-clock 超时 -
WithCancel(parent)：不自带超时逻辑，必须由业务代码决定何时调用cancel()，适合条件式终止（如收到 stop signal） - 混合使用常见：
ctx, cancel := context.WithTimeout(parentCtx, 10*time.Second)，再在异常路径上defer cancel()避免泄漏
HTTP 请求超时必须分层设置
仅对 http.Client 设置 Timeout 字段（即整个请求生命周期）远远不够。真正容易卡住的是连接建立、TLS 握手、响应体读取等环节，需分别控制：
-
Client.Timeout：覆盖从Do()开始到响应 body 读完的总耗时，但不包含 DNS 解析（由 net.Resolver 控制） -
Transport.DialContext：应包装为带超时的 dialer，例如用net.Dialer{Timeout: 5 * time.Second} -
Transport.TLSHandshakeTimeout：默认 10 秒，高延迟网络下建议显式设为 3–5 秒 - 响应体读取：必须用
resp.Body.Read()配合ctx.Done()检查，否则大文件下载可能永远卡在Read上
漏掉任一层，都可能导致“明明设了 5 秒超时，实际卡住 2 分钟”的线上事故。
