Go语言Context超时控制关键在于正确使用WithTimeout、显式调用cancel、信号穿透到底层操作及精准错误判断：优先用WithTimeout而非WithDeadline；必须显式调用cancel（defer仅兜底）；HTTP/DB等操作需用WithContext方法；阻塞逻辑须select监听ctx.Done()；错误须用errors.Is区分DeadlineExceeded与Canceled。
Go语言中Context超时控制的关键不在“设不设”，而在于“怎么设、谁来管、何时生效”。用错地方或漏掉配套动作，超时就形同虚设，甚至引发资源泄漏。
超时起点要明确：WithTimeout比WithDeadline更安全
绝大多数场景应优先使用context.WithTimeout。它接收一个time.Duration，自动基于当前纳秒级时间计算截止点，能正确应对系统休眠、NTP校时等时钟漂移问题。而WithDeadline依赖绝对时间，若机器时间被手动调整或NTP回拨，可能提前触发取消或严重延迟。
- 写
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，语义清晰，无需自己算time.Now().Add(...) - 避免把
WithDeadline当WithTimeout用——硬塞一个time.Now().Add()结果，既多此一举又易出错 - 超时计时从
WithTimeout调用那一刻开始，不是从HTTP请求发出、数据库查询启动或goroutine真正执行那一刻开始
cancel必须显式调用，defer只是兜底
创建WithTimeout时返回的cancel函数不是可选项，而是必需项。不调用它，底层timer和Done()通道不会释放，高频服务运行数小时后内存与goroutine数量会缓慢但持续上涨。
- 正确写法一定是
ctx, cancel := context.WithTimeout(...)，且cancel()要在所有出口处执行——包括正常return、error return、panic恢复后、select的default分支里 -
defer cancel()是基础保障，但无法覆盖panic未recover、或提前return却遗漏cancel的情况；关键路径建议显式调用+defer双保险 - 即使
ctx.Err() == context.DeadlineExceeded已发生，仍需调用cancel()，否则定时器继续驻留
超时信号要穿透到底层阻塞操作
Context本身不杀goroutine，只发信号。如果下游操作不监听ctx.Done()，超时就完全无效。
立即学习“go语言免费学习笔记（深入）”；
- HTTP请求必须用
http.NewRequestWithContext(ctx, ...)构造，并传给client.Do()；同时建议将http.Client.Timeout设为0，避免与context逻辑冲突 - 数据库操作必须用
db.QueryContext(ctx, ...)、tx.ExecContext(...)等上下文感知方法，而非原始Query() - 自定义阻塞逻辑（如轮询、sleep、channel等待）必须用
select主动监听ctx.Done()，不能靠time.Sleep硬等或轮询判断 - 子goroutine中若有多个阻塞点（如先查DB再调API），每个点都要独立检查ctx，否则卡在任一环节都会无视超时
错误处理要区分类型，不能一概而论
收到ctx.Err()后，必须用errors.Is(err, context.DeadlineExceeded)或errors.Is(err, context.Canceled)做类型判断，因为超时与手动取消代表完全不同的业务含义。
- API网关遇到
DeadlineExceeded应记录504并告警，而Canceled（如客户端关闭连接）通常记为499，无需告警 - 后台任务中，超时可能触发降级逻辑，而用户主动取消则应清理中间状态、释放锁等
- 不要仅靠
err != nil统一处理，否则丢失关键诊断线索
