context.DeadlineExceeded 是 context 包主动返回的超时错误，表示操作已超过设定 deadline；它实现 error 接口，应使用 errors.Is(err, context.DeadlineExceeded) 判断，语义区别于 context.Canceled。
context.DeadlineExceeded 是什么错误
它不是 panic，也不是你代码写的错，而是 context 主动返回的“时间到了”信号。当一个带 deadline 的 context 超时，所有监听它的操作（比如 http.Client.Do、database/sql.QueryContext）会立即返回这个错误。
常见现象：HTTP 请求突然返回 context.DeadlineExceeded，但服务端其实没挂；数据库查询卡住几秒后报这个错，而日志里看不到 SQL 执行失败。
- 它实现了
error接口，且是context包里唯一导出的 error 变量，可直接用errors.Is(err, context.DeadlineExceeded)判断 - 别用
==比对字符串，因为不同 Go 版本可能微调错误信息文本 - 它和
context.Canceled是兄弟错误，但语义不同：一个是“时间到”，一个是“被主动取消”
怎么正确设置 HTTP 请求的超时
别只在 http.Client.Timeout 上设值——它只控制整个请求生命周期（从发起到收到响应体结束），不覆盖 DNS 解析、TLS 握手等前置阶段。真要精细控制，得用 context.WithTimeout + req.WithContext。
典型误用：client := &http.Client{Timeout: 5 * time.Second}，看似简单，但遇到 DNS 卡顿或 TLS 重试时，实际耗时可能远超 5 秒。
立即学习“go语言免费学习笔记（深入）”；
- 推荐写法：创建带 deadline 的
context，再传给http.NewRequestWithContext -
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，注意cancel()必须调用，否则可能泄露 goroutine - 如果请求已发出，
cancel()会中断底层连接（TCP 层），但不能保证对方一定停止处理 - HTTP/2 下，取消可能触发 RST_STREAM；HTTP/1.1 则依赖 TCP FIN 或连接关闭
database/sql 查询如何响应 Context 取消
原生 database/sql 支持 QueryContext、ExecContext 等方法，但能否真正中断执行，取决于驱动实现。比如 lib/pq（PostgreSQL）能响应 cancel，而老版本 mysql 驱动可能只是忽略。
常见坑：调用 rows.Close() 后仍看到 goroutine 泄露，或者 cancel 后查询还在数据库里跑着。
- 确保使用支持 context 的驱动最新版，例如
github.com/jackc/pgx/v5比lib/pq响应更快 - 不要在
defer rows.Close()里依赖 context，Close()本身不读取剩余结果，需先rows.Next()遍历完或显式rows.Err()检查 - 长时间查询建议配合
SET statement_timeout = '3s'（PostgreSQL）或MAX_EXECUTION_TIME（MySQL 5.7+）做服务端兜底
为什么 defer cancel() 不总是安全
很多人写 defer cancel() 图省事，但它在函数提前 return 时可能触发过早取消——比如你在中间某步发现参数非法，立刻 return，这时 cancel() 会把还没开始的异步操作也干掉。
更隐蔽的问题：多个 goroutine 共享同一个 ctx，其中一个调了 cancel()，其他全被波及。
- 取消时机必须和业务语义对齐：只有当你确认“后续所有依赖此 ctx 的操作都该停”时，才调
cancel() - 如果函数里启动了子 goroutine 并传入该
ctx，记得用context.WithCancel(ctx)派生新 ctx，避免父 cancel 连坐 - 测试时容易漏掉：mock 函数没检查
ctx.Err()就直接返回，导致 cancel 无效
context 的 deadline 不是魔法开关，它靠协作完成。每个参与方都要主动 select ctx.Done()、检查 ctx.Err()，否则超时就只是个摆设。
