最直接方式是启动时用context.WithTimeout绑定ctx与cancel，确保cancel被调用、下游操作支持ctx、HTTP请求显式传入ctx、统一由ctx控制超时而非Client.Timeout、select监听ctx.Done()退出。
用 context.WithTimeout 启动带超时的 Goroutine 最直接
Go 里没有“给已有 Goroutine 加超时”的魔法，必须从启动那一刻就把它和 context.Context 绑定。最常用的是 context.WithTimeout，它返回一个带截止时间的 ctx 和 cancel 函数。
常见错误是只传 ctx 却忘了调用 cancel —— 这会导致定时器泄漏，尤其在高频请求中内存缓慢上涨。
-
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)是起点，但必须确保cancel()被执行（哪怕提前结束） - 如果 Goroutine 内部要调用 HTTP、数据库或自定义阻塞操作，这些函数得支持
ctx参数，否则超时无效（比如直接写time.Sleep(5 * time.Second)就绕过了 ctx） - 注意
WithTimeout的第二个参数是持续时间，不是绝对时间点；别和WithDeadline混用
HTTP 客户端请求必须显式传 ctx 才能响应超时
很多人以为设置了 http.Client.Timeout 就够了，其实它只控制整个请求生命周期（DNS + 连接 + 写 + 读），且无法被外部主动取消。而 context.Context 可以在任意时刻中断请求，比如用户关闭页面、上游服务已放弃等待。
- 正确姿势是：构造
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)，再用client.Do(req) -
http.Client自身的Timeout字段和WithContext不冲突，但建议关掉前者（设为 0），由 ctx 统一控制，避免逻辑打架 - 如果用了
net/http的中间件（如gorilla/mux），也要确认路由 handler 是否把父 ctx 透传进子 Goroutine，否则超时信号到不了底层
select 配合 ctx.Done() 是唯一可靠退出方式
不能靠轮询或 sleep 等待超时，必须用 select 监听 ctx.Done()。这是 Go Context 机制的契约：只有 Done() channel 关闭，才代表上下文被取消或超时。
立即学习“go语言免费学习笔记（深入）”；
- 典型结构：
select { case <-ctx.Done(): return ctx.Err() // 或 log、清理资源 case result := <-someChan: return result } - 如果 Goroutine 内部有多个阻塞点（比如先读 DB 再调第三方 API），每个都要在对应
select里监听ctx.Done()，否则某一步卡住就永远不响应超时 - 别在
ctx.Done()触发后继续用ctx去发起新请求——此时ctx.Err()已非 nil，多数库会立即返回错误
嵌套 Context 容易漏掉 cancel，用 defer cancel() 不够安全
当 Goroutine 启动另一个 Goroutine，或者函数调用链变长时，cancel() 很容易被遗忘或延迟调用。比如在 defer cancel() 前发生 panic，或者函数提前 return 但 defer 还没跑。
- 更稳妥的方式是：把
cancel当作资源管理的一部分，在明确的退出路径上显式调用（比如每个return前） - 如果用
context.WithCancel或WithTimeout创建子 ctx，父 ctx 的取消会自动级联到子 ctx；但反过来不行——子 ctx 的cancel不影响父 ctx - 调试时可打印
ctx.Err()，常见值是context.DeadlineExceeded（超时）或context.Canceled（手动取消），别只判空
超时控制真正难的不是写那几行 WithTimeout 和 select，而是让整条调用链上的每一步都尊重 ctx，并且每个 cancel 都在恰当时机被调用。漏掉一个环节，超时就形同虚设。
