context.WithTimeout不会自动中断goroutine，仅提供ctx.Done()信号；必须将ctx传入下游可取消操作（如http.Request.WithContext、db.QueryContext）且该操作内部监听ctx.Done()，否则超时无效。
context.WithTimeout 不是“设了就生效”，它只提供信号，不中断任何 goroutine —— 要想超时真正起作用，必须满足两个硬性条件：ctx 被传入下游可取消操作，且该操作内部监听了 ctx.Done()。
为什么调用了 context.WithTimeout 却没超时？
最常见原因是：只创建了带超时的 ctx，但没把它传给真正干活的函数。比如：
- 用
http.Get(url)而不是构造*http.Request后调用req.WithContext(ctx)再交给client.Do() - 调用
db.Query(sql, args...)而不是db.QueryContext(ctx, sql, args...) - 自己写的循环或
time.Sleep完全没检查ctx.Err()或
标准库中只有显式带 Context 后缀的方法（如 QueryContext、Do、ConnContext）才响应超时；裸函数或第三方库若未适配 context，WithTimeout 就是摆设。
context.WithTimeout 和 context.WithDeadline 该怎么选？
绝大多数场景直接用 context.WithTimeout —— 它接收 time.Duration，语义清晰，且自动处理系统休眠、NTP 时间调整等带来的时钟漂移问题。
立即学习“go语言免费学习笔记（深入）”；
context.WithDeadline 接收绝对时间点 time.Time，仅在需要与外部系统对齐截止时刻时才用（例如分布式任务协调、金融结算窗口）。误用它来模拟 “5 秒后超时”（比如手动算 time.Now().Add(5 * time.Second)）反而多了一层出错可能，还失去时钟漂移防护。
必须调用 cancel()，哪怕超时已触发
context.WithTimeout 返回的 cancel 函数不是可选配件，而是资源释放开关：
- 不调
cancel()，底层time.Timer不会停止，持续占用 goroutine 和内存，高频请求下会明显泄漏 - 即使
ctx.Err() == context.DeadlineExceeded已发生，仍需调cancel()来回收 timer - 正确写法永远是：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second); defer cancel()，且defer要放在函数开头附近，不能只在 error 分支里
HTTP handler 中尤其容易漏：如果基于 r.Context() 派生子 ctx，又没 defer cancel()，每个请求都会漏一个 timer。
超时起点不是 IO 开始，而是 WithTimeout 调用时刻
这个细节常被忽略：context.WithTimeout 的倒计时从它被调用那一瞬间就开始，不是从你发起网络请求、执行 SQL 或启动 goroutine 的时刻开始。
这意味着：
- 如果主线程在锁里卡了 2 秒，再调
WithTimeout(ctx, 1*time.Second)，实际只剩不到 1 秒可用 - 想让超时真正从“发请求那一刻”起算，就得把
WithTimeout放到请求构造之后、client.Do()之前 - 嵌套多个
WithTimeout时，外层超时包含内层创建开销，总耗时不等于各层之和
测试时用 time.Sleep 模拟耗时也要小心：它不触发调度器抢占，timer 实际触发可能比预期晚几十毫秒，别依赖它做精确超时验证。
