最推荐使用 context.WithTimeout；它语义清晰、自动处理时钟漂移，且比 WithDeadline 更安全；必须显式调用 cancel() 释放资源，超时起点是 WithTimeout 调用时刻而非 IO 发起时刻。
Go 里用 context.WithTimeout 是最直接、最可控的超时方式，但多数人栽在没调用 cancel() 或误判超时起点上。
超时函数选 WithTimeout 还是 WithDeadline
选 WithTimeout——它内部就是基于当前时间 + 持续时间算出 deadline，语义更清晰，也更符合“我只想等 5 秒”这种直觉。除非你明确知道截止绝对时间点（比如“必须在 2024-10-15T14:30:00Z 前结束”），否则不用 WithDeadline。
常见错误：把 time.Now().Add(5 * time.Second) 算出来的时间硬塞进 WithDeadline，结果和 WithTimeout 行为一致，还多了一层手动计算，容易出错。
-
WithTimeout接收time.Duration，自动处理时钟漂移和系统休眠影响（底层用的是runtime.nanotime） -
WithDeadline接收绝对time.Time，如果机器时间被 NTP 调整或回拨，可能提前或延后触发取消 - HTTP 客户端、数据库连接池等标准库组件都默认适配
context.Context，传进去就能生效
必须手动调用 cancel()，哪怕超时已触发
不调 cancel() 不会泄漏 goroutine，但会泄漏 timer 和 context 内部的 channel，尤其在高频请求场景下内存增长明显。Go 1.21+ 虽做了部分优化，但依然建议显式调用。
典型反模式：ctx, _ := context.WithTimeout(ctx, time.Second) —— 忘了接收 cancel 函数，也没地方调。
- 正确写法：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，然后 在 defer 或逻辑结束处调用cancel() - 即使
ctx.Err() == context.DeadlineExceeded已发生，cancel()仍需执行，否则 timer 不释放 - HTTP handler 中常漏掉：panic 恢复后、return 前、select default 分支里都要确保
cancel()执行
超时起点从 WithTimeout 调用那一刻开始算
不是从你发起 IO（比如 http.Do）或启动 goroutine 的时刻开始。中间任何阻塞、调度延迟都会计入超时总时间。
现象举例：主线程卡在锁里 2 秒，再调 WithTimeout(..., 1*time.Second)，实际只剩不到 1 秒可用，极易误报超时。
- 如果想“真正从网络请求发出那一刻计时”，得在发请求前才创建超时 context，而不是在 handler 入口就建好
- 链路中多个
WithTimeout嵌套时，外层超时包含内层创建开销，别指望嵌套后总耗时严格等于各层之和 - 测试时用
time.Sleep模拟耗时要小心：它不触发调度器抢占，可能让 timer 实际触发比预期晚几十毫秒
超时控制真正难的不是写那两行代码，而是厘清“谁该负责取消”“超时是否覆盖初始化阶段”“cancel 调用路径是否全覆盖”。漏掉一个分支，问题就藏在压测后期才冒出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
