最直接的方式是在goroutine中使用context.WithTimeout；需将ctx作为首参传入，用select监听ctx.Done()，并务必调用cancel()防止timer泄漏，子goroutine必须继承父ctx而非用Background()。
goroutine 里用 context.WithTimeout 是最直接的方式
不是所有 goroutine 都需要超时，但只要涉及外部调用（HTTP、DB、RPC）、用户请求响应、或不确定耗时的计算，就必须加。不加就可能卡死整个服务，尤其在高并发下。
核心是：把 context.Context 作为第一个参数传进 goroutine 启动函数里，在内部用 select 监听 ctx.Done()；一旦超时，ctx.Err() 会返回 context.DeadlineExceeded。
-
context.WithTimeout返回新的ctx和cancel函数，后者必须调用，否则可能泄漏 timer - 超时时间从调用
WithTimeout的那一刻开始计，不是从 goroutine 启动开始 - 如果 goroutine 已经结束，
cancel()调用是安全的，但不调用会导致后台 timer 继续跑完（小概率泄漏）
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // 别漏掉
<p>go func(ctx context.Context) {
select {
case <-time.After(10 * time.Second):
fmt.Println("done")
case <-ctx.Done():
fmt.Println("timeout:", ctx.Err()) // context.DeadlineExceeded
}
}(ctx)HTTP client 请求自带 context 支持，别自己包一层 select
很多人习惯给 http.Get 套个 goroutine + select 等超时，其实完全没必要 —— http.Client 原生支持 Context，且更精准（能中断底层连接、DNS 查询等）。
-
http.DefaultClient不读取 context，必须显式用&http.Client{Timeout: ...}或带WithContext的方法 - 正确姿势是：构造带 timeout 的 client，或直接用
req.WithContext(ctx)注入 - 如果只设
http.Client.Timeout，它只控制整个请求生命周期，不响应中间取消；用 context 才能真正中断进行中的读写
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39">https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39</a>", nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 这里才是真正的超时路径
}
}子 goroutine 必须继承父 context，不能用 context.Background()
常见错误：主 goroutine 创建了带 timeout 的 ctx，但在启动子 goroutine 时，又用 context.Background() 新建一个，导致子任务完全不受控。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 子 goroutine 应该接收父 ctx 并直接使用，或用
context.WithValue/WithCancel衍生新 ctx（注意 cancel 时机） - 如果子任务需要独立超时，应该用
context.WithTimeout(parentCtx, ...)，这样父 ctx 取消时，子 ctx 也会连带取消（层级传播） - 用
Background()就等于放弃控制权，尤其在微服务调用链中，会破坏全链路超时传递
// ❌ 错误：子 goroutine 脱离控制
go func() {
ctx := context.Background() // 完全无视上游 timeout
doWork(ctx)
}()
<p>// ✅ 正确：继承并可选叠加
go func(ctx context.Context) {
childCtx, _ := context.WithTimeout(ctx, 2*time.Second)
doWork(childCtx)
}(parentCtx)注意 time.AfterFunc 和 time.Sleep 不受 context 控制
这两个函数是纯时间操作，和 context 没有任何关系。想靠它们实现“超时取消”，必须手动配合 select + ctx.Done()，否则哪怕 context 已取消，它们仍会执行到底。
-
time.Sleep是阻塞调用，无法被中断；必须用select等待time.After或ctx.Done() -
time.AfterFunc一旦注册就不可撤销，即使 ctx 已 cancel，回调仍会触发 —— 如果要可取消，得自己封装或改用time.Timer+Stop() - 高频场景如重试逻辑，最容易在这里漏掉 context 检查，导致“超时后还在疯狂重试”
// ❌ 错误：Sleep 不响应 cancel
time.Sleep(5 * time.Second) // 即使 ctx.Done() 已关闭，也照睡不误
<p>// ✅ 正确：用 select 等待可取消信号
select {
case <-time.After(5 * time.Second):
// 超时逻辑
case <-ctx.Done():
return // 提前退出
}context 超时控制的复杂点不在 API 多难，而在于「谁创建、谁传递、谁 cancel、谁监听」这四个动作是否闭环。漏掉任意一环，就等于没加。尤其要注意 defer cancel() 的位置、子 goroutine 的 ctx 来源、以及所有阻塞操作是否真的可中断。
