context.WithTimeout 无效果是因为未将 ctx 传入下游函数或函数未监听 ctx.Done()；超时后 ctx.Err() 返回 context.DeadlineExceeded，应使用 errors.Is(err, context.DeadlineExceeded) 判断。
Go 里用 context.WithTimeout 设置超时，不是“加个 context 就自动超时”，必须显式传给下游函数，且该函数得真正检查 ctx.Done() —— 否则超时纯属摆设。
为什么 context.WithTimeout 调用了却没效果？
常见错误是只创建了带超时的 ctx，但没把它传进实际执行 IO 或计算的函数里。比如调用 http.Client.Do 时不传 ctx，或自己写的数据库查询函数压根不接收 ctx 参数。
关键点：
-
context本身不中断任何 goroutine，它只是提供一个信号通道（ctx.Done()） - 所有可能阻塞的操作，必须主动监听
ctx.Done()并退出 - 标准库中如
http.Client、sql.DB.QueryContext等才支持context；裸写time.Sleep或循环不检查ctx，就完全无视超时
WithTimeout 和 WithDeadline 该怎么选？
两者本质一样：WithTimeout 是基于当前时间 + 持续时间算出 deadline，WithDeadline 直接指定绝对时间点。选哪个取决于你控制超时的粒度。
立即学习“go语言免费学习笔记（深入）”；
使用建议：
- 对外部 API 调用、用户请求处理，用
WithTimeout更自然（比如“最多等 5 秒”） - 需要和外部系统对齐截止时间（如分布式任务协调），用
WithDeadline避免本地时钟漂移影响 - 注意：两个函数返回的
ctx都要配合defer cancel()，否则可能泄漏 timer
超时后 ctx.Err() 返回什么？怎么判断？
超时触发后，ctx.Err() 返回 context.DeadlineExceeded，这是一个预定义的 error，不是字符串匹配。
正确判断方式：
- 用
errors.Is(err, context.DeadlineExceeded)（推荐，兼容 future 变更） - 或直接比较
err == context.DeadlineExceeded（当前安全，但不如errors.Is健壮） - 不要用
strings.Contains(err.Error(), "timeout")—— 错误信息可能变，且非所有 timeout error 都含 timeout 字样
示例：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
select {
case <-time.After(3 * time.Second):
fmt.Println("done")
case <-ctx.Done():
if errors.Is(ctx.Err(), context.DeadlineExceeded) {
fmt.Println("timed out")
}
}自定义函数怎么真正支持 context 超时？
如果你写了一个可能阻塞的函数（比如轮询状态、重试逻辑），想让它响应 context 超时，就得在循环或等待点插入检查。
实操要点：
- 函数签名必须接收
ctx context.Context参数 - 每次进入可能阻塞前（如
time.Sleep、ch 、<code>db.QueryRowContext），先 select 判断ctx.Done() - 不要把
ctx存到结构体长期持有——容易忘记 cancel，或导致生命周期混乱 - 如果内部启了 goroutine，记得用
ctx派生子 context（如childCtx, _ := context.WithCancel(ctx)），并在 goroutine 结束时 cancel
最容易被忽略的是：超时不是魔法开关，它依赖每一层都主动配合。从 HTTP 客户端、数据库驱动，到你自己写的 for-loop，漏掉任意一环，context 就退化成装饰品。
