context.WithTimeout不能直接套用是因为database/sql的Query、Exec等原生方法完全忽略context，必须显式使用QueryContext、ExecContext等支持context的接口才能触发超时取消；否则查询会持续阻塞，导致goroutine泄漏和请求hang死。
context.WithTimeout 为什么不能直接套在 database/sql 查询上
因为 database/sql 的 QueryContext、ExecContext 等方法才真正感知 context，而原生的 Query、Exec 完全忽略 context。如果你只用 context.WithTimeout 创建 ctx 却调用 db.Query(...)，超时根本不会触发 cancel，查询会一直卡住直到数据库返回或网络断开。
常见错误现象：context deadline exceeded 永远不出现，goroutine 泄漏，HTTP 请求 hang 死。
- 必须显式使用带
Context后缀的方法（QueryContext、QueryRowContext、ExecContext） - ctx 需在调用前创建，且 timeout 值要略大于预期最大数据库响应时间（比如 DB RT P99 是 800ms，设 1200ms）
- 注意：MySQL 驱动（如
github.com/go-sql-driver/mysql）从 v1.7+ 才完整支持 context cancel；旧版可能忽略ctx.Done()
在 Gin/Gin 中给每个 HTTP handler 绑定查询超时 ctx
Gin 本身不自动传递 context 超时，得手动从 c.Request.Context() 派生新 ctx，并传给 DB 方法。别直接用 c.Request.Context() —— 它默认没有 deadline，除非你提前用 gin.Context.Set() 注入过，但那不安全。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 handler 内用
ctx, cancel := context.WithTimeout(c.Request.Context(), 2*time.Second)，然后 defercancel() - 把
ctx传给 DAO 层，DAO 必须用db.QueryRowContext(ctx, ...)，而非db.QueryRow(...) - 如果 DAO 还调了其他下游（如 Redis、HTTP client），也应复用同一个
ctx，保证整条链路统一超时 - 注意：Gin 的
c.AbortWithError(http.StatusGatewayTimeout, err)应在ctx.Err() == context.DeadlineExceeded时触发，而不是等 query 返回再判断
SQL 查询本身慢，但 context 已 cancel，驱动是否真能中断连接
答案取决于驱动和数据库协议支持程度。MySQL 的 mysql 驱动在收到 ctx.Done() 后会尝试发送 KILL QUERY（需配置 readTimeout 和启用 interpolateParams=true），PostgreSQL 的 pgx 则通过 CancelRequest 协议主动中断。但若网络已阻塞、DB 连接卡在握手阶段，cancel 可能失效。
关键参数和兼容性：
- MySQL 驱动：确保连接串含
readTimeout=5s&writeTimeout=5s，否则底层 net.Conn 不响应 cancel - PostgreSQL（
pgx）：推荐用pgxpool.Pool，它内置 context 支持；避免用pgx.Connect()原始连接 - SQLite 不支持 cancel，
context对它无效——本地文件操作无法被中断，只能靠查询前预估复杂度 - 超时后检查
err：必须是errors.Is(err, context.DeadlineExceeded)或errors.Is(err, context.Canceled)，不要用字符串匹配
多个 DB 查询嵌套时如何共享同一超时 ctx
不要为每个查询单独建 WithTimeout，否则超时时间叠加、语义混乱。正确做法是上游统一控制总耗时，所有子查询复用同一个 ctx。
典型场景：一个用户详情接口查 user 表 + order 表 + profile 表。错误写法是三个 QueryRowContext 各自带 1s timeout；正确写法是：
- 在 handler 顶层建一次
ctx, cancel := context.WithTimeout(...) - DAO 层函数签名统一接收
ctx context.Context，内部不做二次 timeout - 若某次查询需更短时限（比如“查缓存失败后 fallback 到 DB”，DB 查询只给 300ms），用
context.WithTimeout(ctx, 300ms)派生子 ctx，但父 ctx 仍主导整体生命周期 - 注意：子 ctx 的 cancel 不影响父 ctx，但父 ctx cancel 会同时 cancel 所有子 ctx
容易被忽略的是：事务内多个 ExecContext 共享同一个 ctx，一旦超时，未提交的事务会因连接关闭而自动 rollback —— 这是期望行为，但需确保你的业务逻辑能处理这种中断状态。
