context.withtimeout 能提供可取消信号并配合函数内对 ctx.done() 的检查实现真正中断，而 time.afterfunc 仅触发回调无法停止运行中的函数。
为什么用 context.WithTimeout 而不是 time.AfterFunc
因为 time.AfterFunc 只能触发回调，无法中断正在运行的函数；而 context.WithTimeout 提供的是可取消信号，配合函数内部对 ctx.Done() 的检查，才能真正实现“超时即停”。很多初学者误以为启动一个定时器就能控制函数执行时长，结果发现 goroutine 还在后台跑——根本没停。
典型场景：调用外部 HTTP 接口、数据库查询、或执行一段可能阻塞的计算逻辑。这些操作必须主动响应 context 取消信号，否则超时只是“通知到了”，任务照常执行。
-
context.WithTimeout返回context.Context和cancel函数，后者必须被调用（尤其在 defer 中），否则可能泄漏 goroutine - 超时时间从
WithTimeout调用那一刻开始计时，不是从函数实际执行开始 - 如果函数本身不读取
ctx.Done()或忽略ctx.Err()，超时控制完全失效
怎么写一个支持 context 超时的函数
关键不是加个参数，而是让函数在每处可能阻塞的地方检查 ctx.Done()。比如 I/O 操作、channel 收发、循环中的 sleep 等。
示例：一个模拟耗时请求的函数：
func doWork(ctx context.Context) error {
select {
case context.DeadlineExceeded 或 <code>context.Canceled</code>
}
}
注意：time.After 本身不响应 cancel，所以必须用 select + ctx.Done() 包裹；若函数内部有多个步骤，每个步骤前都应加类似检查。
- 不要只在函数开头检查
ctx.Err()，那只能防止启动，不能中断进行中任务 - 对
http.Client，直接传入带 timeout 的context即可，它内部已处理；但自定义逻辑必须手动轮询ctx.Done() - 避免在
select中漏掉default分支——这会导致非阻塞轮询，消耗 CPU
context.WithTimeout 和 context.WithDeadline 选哪个
绝大多数情况用 context.WithTimeout 更直观：你关心的是“最多等多久”，而不是“必须在某个绝对时间点前完成”。WithDeadline 适合定时任务调度（如“每天凌晨 2 点执行”），但容易因系统时间跳变出错。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
两者返回的 Context 行为一致，区别仅在于时间源：WithTimeout 是相对当前时间的偏移量，WithDeadline 是绝对时间点。
- 测试时
WithTimeout更易 mock 和断言，因为不依赖系统时钟 - 如果函数需要跨多个子调用传递超时，始终用同一个
ctx，不要层层重新调用WithTimeout，否则会叠加超时时间 -
cancel()必须调用，哪怕超时已触发——这是释放资源的关键，否则 context 可能持续持有引用
常见错误：超时了但 goroutine 还在跑
最典型的症状是：日志里看到 context deadline exceeded，但后续发现函数里的打印、数据库写入、甚至 time.Sleep 仍在执行。原因只有一个：函数没在阻塞点响应 ctx.Done()。
例如这样写就无效：
func badExample(ctx context.Context) {
time.Sleep(5 * time.Second) // 完全不检查 ctx！超时后仍睡满 5 秒
}
正确做法是用 time.Sleep 的替代方案，或拆成小步并检查：
func goodExample(ctx context.Context) error {
ticker := time.NewTicker(100 * time.Millisecond)
defer ticker.Stop()
for i := 0; i
- 第三方库是否支持 context？查文档，看方法签名是否接收
context.Context参数；不支持的库无法被超时中断 - goroutine 泄漏往往源于忘记调用
cancel()，尤其在 error early return 时，务必用defer cancel() - 超时误差可能达几十毫秒，别指望精确到毫秒级——这是 Go runtime 调度和 timer 实现决定的
超时控制不是加个 context 参数就完事，核心在于函数是否真正尊重那个 Done() channel。漏掉一次检查，整个超时机制就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
