go中context.withtimeout控制超时需完成“发信号+听信号+收尾”三步，缺一导致goroutine泄漏；95%场景应优先用withtimeout而非withdeadline，且cancel必须在每个出口调用一次。
Go 里用 context.WithTimeout 控制超时，不是“设了就停”，而是“发信号+听信号+收尾”三件事缺一不可。漏掉任意一环，任务照跑、goroutine 照 leak、内存照涨。
为什么 ctx.Err() == context.DeadlineExceeded 但任务还在跑
因为下游没监听 ctx.Done() —— Context 只广播信号，不杀 goroutine。
- HTTP 请求用了
http.NewRequest()而不是http.NewRequestWithContext(ctx, ...)，或client.Do(req)没传带 ctx 的 req - 数据库调用写了
db.Query(sql)，而不是db.QueryContext(ctx, sql) - 自定义逻辑里有
time.Sleep(5 * time.Second)或for range ch，但没在select中同时监听ctx.Done() - 第三方库（如老版本
redis-go）不支持 context，得手动配conn.SetReadDeadline()
context.WithTimeout 和 context.WithDeadline 怎么选
95% 场景直接用 context.WithTimeout：它基于单调时钟，抗休眠、抗 NTP 回拨，语义也更直白。
-
context.WithTimeout(parent, 3*time.Second)：从这行代码执行起倒计时，安全可靠 -
context.WithDeadline(parent, time.Now().Add(3*time.Second))：传绝对时间，若系统时间被人为调慢或虚拟机休眠后唤醒，deadline 可能已过，ctx 立即取消 - 别写
context.WithDeadline(ctx, time.Now().Add(d))—— 这和WithTimeout行为一致，还多一次计算，易出错 - 真需要
WithDeadline的场景极少：比如对接 Airflow，必须严格对齐外部调度器的截止时间戳
cancel 函数必须调，但不能乱调
不调 cancel() 会泄漏 timer 和 channel；重复调或 panic 后未调，都会引发问题。
- 每个出口都要覆盖：
return前、if err != nil分支、select的default分支、甚至recover()后 -
defer cancel()是基础，但不够：panic 未 recover 时 defer 不执行；提前 return 时可能跳过 defer - 别在一个函数里多次
defer cancel()—— 第二次调用静默失败，你以为释放了，其实没 -
context.WithTimeout内部已注册定时器，超时自动触发cancel()；你只需在非超时路径（如中间出错）主动调一次，且仅一次
超时起点不是 IO 开始，而是 WithTimeout 执行时刻
这是最常误判的点：2 秒超时，从 ctx, cancel := context.WithTimeout(...) 那一刻就开始倒计时，不是从 client.Do() 发出请求、也不是从 db.QueryContext() 开始执行 SQL 算起。
- 如果
WithTimeout后还做了大量同步计算（比如解析参数、校验 token），这部分也会计入超时时间 - 想精确控制“IO 阶段”超时？得在真正发起 IO 前才调
WithTimeout，而不是在 handler 开头就套一层 - 多个子操作共享同一 ctx 时，一个超时会 cancel 全部；要独立控制，就得为每个操作派生新 ctx（如
context.WithTimeout(dbCtx, 5*time.Second)）
真正难的不是写那行 context.WithTimeout，而是确保所有阻塞点都响应 ctx.Done()，且每个 cancel() 都落在该落的地方——它是个链路级契约，不是单点开关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
