context.WithTimeout 本质是让任务主动退出而非外部杀协程，需在外层统一控制整个任务链超时，并将 ctx 传入所有阻塞函数且定期检查 ctx.Done()。
用 context.WithTimeout 包裹 goroutine 启动逻辑
超时控制的本质是让任务在指定时间后主动退出，而不是靠外部轮询或杀协程。Go 标准库推荐用 context 传递取消信号，context.WithTimeout 是最直接的方案。
常见错误是只对单个 I/O 操作加超时（比如 http.Client.Timeout），但整个任务链（如数据库查询 + JSON 解析 + 第三方 API 调用）可能耗时更长，必须在外层统一控制。
- 超时时间应从任务入口开始计时，不是从某个子步骤开始
-
context.WithTimeout返回的ctx需要传入所有可能阻塞的函数（如http.Do、db.QueryContext、time.Sleep） - goroutine 内部必须定期检查
ctx.Done()，不能只依赖一次调用
func runTask(ctx context.Context) error {
select {
case <-time.After(2 * time.Second):
return nil // 模拟正常完成
case <-ctx.Done():
return ctx.Err() // 超时或取消
}
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
defer cancel()
err := runTask(ctx)
if err != nil {
log.Println("task failed:", err) // context deadline exceeded
}}
避免 select 中漏掉 default 导致忙等
在需要非阻塞检查 context 的循环中（比如轮询状态、重试逻辑），直接写 select { case 会永久阻塞，除非上下文结束——这违背“及时响应”的初衷。
典型场景：一个后台任务需每 100ms 检查一次条件，同时支持超时退出。若没处理好，它可能卡在最后一次 select 等待中，错过超时信号。
- 必须加
default分支实现非阻塞检查 - 或改用
select+time.After组合，但注意time.After会持续分配 timer，高频场景建议复用time.Ticker - 每次循环都应先检查
ctx.Err() != nil，比等待ctx.Done()更轻量
func pollingTask(ctx context.Context) error {
ticker := time.NewTicker(100 * time.Millisecond)
defer ticker.Stop()
for {
select {
case <-ctx.Done():
return ctx.Err()
case <-ticker.C:
// 执行实际工作
if done := checkCondition(); done {
return nil
}
default:
// 防止空转，短暂让出
runtime.Gosched()
}
}}
慎用 time.AfterFunc 单独管理超时
time.AfterFunc 看似简单，但它和 goroutine 之间没有生命周期绑定。超时触发后，原任务可能仍在运行，造成资源泄漏或竞态。
常见误用：启动 goroutine 后立刻调用 time.AfterFunc 发送取消信号，但目标 goroutine 并未监听该信号，或已提前退出
，导致信号被忽略；更糟的是，如果任务已结束，AfterFunc 还在往已关闭 channel 发送，引发 panic。
，导致信号被忽略；更糟的是，如果任务已结束，-
time.AfterFunc适合无状态、纯副作用操作（如打日志、发告警），不适合任务控制 - 它无法感知目标 goroutine 是否存活，也不能回收其资源
- 与
context方案相比，缺乏可组合性（比如嵌套超时、取消链传播）
并发任务组统一超时要用 errgroup.Group
当多个 goroutine 并行执行且需共享同一超时边界时（例如同时请求 3 个微服务），不能每个都单独设超时——那样会导致部分任务提前退出，而整体结果不可控。
errgroup.Group 自动将父 context 透传给所有子 goroutine，并在任一出错或超时时自动取消其余任务。
- 必须用
eg.Go(func() error { ... })启动任务，不能直接 go 启动 - 所有任务函数签名必须是
func() error，内部需使用传入的ctx（即eg.WithContext返回的那个） - 如果某任务提前返回 error，其他正在运行的任务会收到 context 取消信号，但是否响应取决于它们自身实现
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
g, ctx := errgroup.WithContext(ctx)
g.Go(func() error {
return callServiceA(ctx)
})
g.Go(func() error {
return callServiceB(ctx)
})
if err := g.Wait(); err != nil {
log.Println("at least one service failed:", err)
}}
真正难的不是写对一个 context.WithTimeout，而是确保整条调用链上每个可能阻塞的点都接收并响应这个 ctx —— 尤其是第三方库封装的函数，得查文档确认是否支持 Context 版本。
