超时控制必须用 context.WithTimeout，因其能自动传播取消信号并释放资源；time.After 或 select 轮询无法中断下游操作，易致 goroutine 和连接泄漏。
超时控制必须用 context.WithTimeout，不是 time.After 或 select 手动轮询
直接用 time.After 或自己写 select + time.After 看似能“模拟”超时，但无法向下游传递取消信号，HTTP 客户端、数据库驱动、goroutine 链路里的子操作全会继续执行，资源泄漏风险极高。
正确做法是用 context.WithTimeout 生成带截止时间的 context.Context，它会在超时自动调用 cancel()，所有监听该 context 的操作（如 http.Client.Do、sql.DB.QueryContext）都会立即中断。
-
context.WithTimeout(parent, 5*time.Second)返回ctx和cancel函数；务必在函数退出前调用cancel()（通常用defer cancel()） - 不要把返回的
cancel忘记调用——否则底层定时器不释放，长期运行服务会出现 goroutine 泄漏 - 超时时间从调用
WithTimeout开始计时，不是从请求真正发起时开始；若上下文已含 deadline，新 deadline 不能晚于原 deadline
HTTP 请求超时必须传 ctx 给 http.Client.Do，而非只设 Client.Timeout
http.Client.Timeout 只控制整个请求生命周期（连接 + 写请求 + 读响应），且无法被外部主动取消；而 Do 接收 *http.Request，其 Request.Context() 才决定是否响应 cancel 信号。
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel()req, _ := http.NewRequestWithContext(ctx, "GET", "https://www./link/46b315dd44d174daf5617e22b3ac94ca", nil) client := &http.Client{} resp, err := client.Do(req) // 这里才会真正响应 ctx 超时或 cancel() if err != nil { // 可能是 context.DeadlineExceeded if errors.Is(err, context.DeadlineExceeded) { log.Println("request timed out") } return } def
er resp.Body.Close()
er resp.Body.Close()- 即使设置了
Client.Timeout，若没传 context，超时后 goroutine 仍可能卡在 read body 阶段 - 错误判断优先用
errors.Is(err, context.DeadlineExceeded)，而不是字符串匹配"context deadline exceeded"，避免版本差异导致误判 - 如果请求已发出但服务端迟迟不响应，只有 context 能强制断开底层 TCP 连接（取决于 Transport 实现，Go 1.19+ 默认支持）
数据库查询必须用 QueryContext / ExecContext，不能用旧版无 context 方法
像 db.Query、db.Exec 这类老接口完全忽略 context，哪怕你传了带 timeout 的 ctx，SQL 执行依然不会中断。必须显式使用带 Context 后缀的方法。
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel()rows, err := db.QueryContext(ctx, "SELECT * FROM users WHERE status = ?", "active") if err != nil { if errors.Is(err, context.DeadlineExceeded) { log.Println("query timed out") } return } defer rows.Close()
- MySQL 驱动（如
go-sql-driver/mysql）和 PostgreSQL 驱动（如lib/pq或jackc/pgx）都要求 context 传入才能触发 cancel；否则即使超时，连接仍占用、事务可能挂起 - 注意：有些驱动对 cancel 支持不完整（如旧版 SQLite），需查对应驱动文档确认是否真正中断执行
- 事务内多个操作应共用同一个 ctx，避免某个子操作超时后其他操作还在跑
自定义操作中监听 ctx.Done() 要用 select + case ，别用轮询或忽略
当你封装一个需要长时间运行的函数（比如轮询第三方 API、处理大文件流），必须主动检查 ctx.Done() 并及时退出，否则 context 失去意义。
func fetchWithRetry(ctx context.Context, url string) error {
for i := 0; i < 3; i++ {
select {
case <-ctx.Done():
return ctx.Err() // 立即返回，不重试
default:
}
resp, err := http.Get(url)
if err == nil {
resp.Body.Close()
return nil
}
time.Sleep(time.Second)
}
return errors.New("failed after retries")}
- 每次循环前检查
ctx.Done()，而不是只在开头检查一次——因为超时可能发生在任意重试间隙 - 不要在
select中加default:分支做“非阻塞尝试”，这会让 goroutine 疯狂空转；真要非阻塞，用select { case - 如果操作本身不可中断（如正在写磁盘），至少要在关键节点插入
select { case 检查点
context 超时不是“加个参数就完事”，关键在于整条调用链是否每个环节都接收并响应了 ctx；漏掉一环（比如忘了改 Query 为 QueryContext），前面所有 timeout 设置就等于没设。
