context.WithTimeout传给QueryContext才有效，必须显式传入db.QueryRowContext等支持context的方法，否则超时无效；需配合DSN级timeout、连接池配置及驱动支持，分层实现真正超时控制。
context.WithTimeout 传给 QueryContext 才有效
数据库操作超时不是靠 context.WithTimeout 单独实现的，必须把返回的 ctx 显式传给支持 context 的方法，比如 db.QueryRowContext、db.ExecContext 或 tx.QueryContext。标准库 database/sql 从 Go 1.8 起才提供这些带 Context 后缀的函数；用 QueryRow 这类老接口，哪怕 ctx 已超时，查询照样卡住不返回。
常见错误现象：ctx.Err() 已是 context.DeadlineExceeded，但 db.QueryRow 仍阻塞，日志里看不到超时触发痕迹。
- MySQL 驱动（如
go-sql-driver/mysql）对 query cancel 支持有限：它依赖 MySQL 服务端是否响应KILL QUERY，本地连接或旧版本 MySQL 可能完全忽略 - PostgreSQL 驱动（
lib/pq或pgx）响应更及时，尤其pgx默认启用 cancel 支持 - SQLite 不支持真正的 query cancel，
QueryContext只能中断后续调用，无法中止正在执行的语句
超时起点不是 SQL 发出时刻，而是 WithTimeout 调用时刻
你写 ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)，计时器立刻启动——中间任何耗时都会吃掉这 2 秒。比如连接池等待空闲连接花了 800ms，DNS 解析又耗 300ms，真正留给 SQL 执行的时间只剩不到 900ms。
更隐蔽的问题：如果 handler 入口就创建超时 ctx，但业务逻辑先做了校验、鉴权、参数解析等非 DB 操作，这些时间全算进超时里，DB 实际可用时间远低于预期。
- 推荐做法：在真正要发起 DB 调用前一刻再派生超时 ctx，例如
dbCtx, dbCancel := context.WithTimeout(ctx, 1500*time.Millisecond) - 避免复用同一个
ctx多次调用QueryRowContext：一旦某次调用超时，ctx.Done()关闭，后续所有基于它的 DB 调用会立即失败 - 别在事务里混用不同超时 ctx：一个
tx.QueryContext用 A ctx，另一个用 B ctx，cancel 行为不可预测
cancel() 必须显式调用，defer 不够保险
context.WithTimeout 底层启动一个 time.Timer，不调 cancel() 就不会停。高频请求下，timer 泄漏会导致 goroutine 和内存缓慢增长，Go 1.21+ 虽有优化，但问题依然存在。
典型翻车点：handler 里有多个 return 分支，defer cancel() 只覆盖主流程，panic、error 提前 return、select default 分支都可能跳过 defer。
- 最稳妥写法：在每个可能退出的位置前加
cancel()，或统一用defer cancel()+recover()拦截 panic - 不要写
_, cancel := context.WithTimeout(...)：丢掉ctx还好说，丢掉cancel函数等于主动泄漏 - 如果 DB 调用已返回（无论成功或失败），应立刻调用
cancel()，别等函数结束——延迟释放 timer 没好处
别只靠 context，DSN 和连接池也要设 timeout
单靠 QueryContext 无法解决所有阻塞。MySQL 默认不启用 readTimeout，底层 socket 读可能挂住几十秒；连接池获取连接超时（db.SetConnMaxLifetime、db.SetMaxOpenConns）也不受 context 控制。
真实线上场景中，context.DeadlineExceeded 往往和 i/o timeout、connection refused 混在一起，光看 ctx.Err() 容易误判根因。
- MySQL DSN 中加上
readTimeout=2s&writeTimeout=2s，强制底层 socket 级超时 - 调用
db.SetConnMaxIdleTime(30 * time.Second)避免空闲连接拖慢新请求获取 - 如果用
pgx，启用pgx.ConnConfig.CancelFunc并配好CancelRequest地址，才能真正 kill 正在运行的查询 - 永远不要同时开启
http.Client.Timeout和 context 超时——它们冲突，优先级混乱，错误信息难定位
实际部署时最容易被忽略的是：超时控制是分层的，context 只管“函数调用是否返回”，不管“底层 socket 是否断开”或“连接池是否卡死”。 你得在 DSN、驱动配置、SQL 执行、连接池管理四个层面都埋好 timeout，缺一不可。
