context.withtimeout没生效的最常见原因是下游函数未接收或检查ctx；超时起点是withtimeout调用完成时刻；判断超时应使用errors.is(err, context.deadlineexceeded)；cancel()必须调用以避免timer泄漏。
context.WithTimeout 为什么没生效？
最常见的情况是：调用了 context.WithTimeout，但下游函数压根没接收或检查这个 ctx。
比如你写了：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
http.Get("https://example.com") // ❌ 没传 ctx，超时完全无效
正确做法必须用支持 context 的 API，例如：
-
http.Client.Do(req.WithContext(ctx))或直接构造带 context 的*http.Request -
db.QueryRowContext(ctx, query)而不是db.QueryRow(query) - 自己写的轮询函数，签名得是
func(ctx context.Context) error，并在循环中select监听ctx.Done()
记住：context 不会自动中断任何 goroutine，它只提供一个信号通道——你不监听，它就永远沉默。
超时起点从哪算起？
context.WithTimeout 的计时起点是它被调用的那一行代码执行完成的时刻，不是你发起 IO 的时刻，更不是 goroutine 启动的时刻。
这意味着：
- 如果在 handler 开头就创建了超时 ctx，但中间有锁竞争、日志阻塞、或其它同步操作耗时 800ms，那留给 HTTP 请求的实际时间只剩 1.2s（假设设了 2s）
- 不要在业务逻辑深处才创建超时 ctx——越晚建，可用时间越少；想“从发请求那一刻开始计时”，就得在调
http.Do前一刻才调WithTimeout - 嵌套多个
WithTimeout时，外层超时包含内层创建开销，总耗时不等于各层之和
怎么安全判断是不是超时？
ctx.Err() 返回的是一个 error 值，不是字符串。超时触发后，它等于 context.DeadlineExceeded，这是一个导出的变量，类型是 error。
所以判断方式只有两种靠谱的：
- 推荐：
errors.Is(err, context.DeadlineExceeded)—— 兼容未来可能的底层变更 - 当前可用：
err == context.DeadlineExceeded—— 简单直接，但不如errors.Is健壮
绝对不要写：strings.Contains(err.Error(), "timeout")。错误信息可能随版本变化，而且有些非超时错误（比如网络断连）也可能含 “timeout” 字样。
cancel() 必须调，哪怕已经超时
漏掉 cancel() 不会导致 goroutine 泄漏，但会泄漏 timer 和内部 channel，尤其在高频请求下内存持续上涨。
典型陷阱：
-
ctx, _ := context.WithTimeout(...)—— 忘了接收cancel函数，根本没法调 - panic 恢复后没调
cancel()，或者select的default分支里直接 return，跳过了 defer - 认为 “超时已发生，cancel 就没必要了” —— 错。timer 不释放，资源就一直挂着
建议把 cancel() 和资源清理逻辑绑在一起，比如数据库连接 close + cancel() 放同一个 defer 里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
