Go context 取消了但下游查询没有停止

Go 里的 context 取消后，下游查询仍然没有停止，最常见的原因不是 cancel() 没有执行，而是取消信号没有沿调用链传到真正执行查询的位置。若代码仍调用 db.Query，或者在数据访问层重新创建了 context.Background()，数据库操作就看不到上游的 Done 信号。

正确做法是让请求的 ctx 一直传到 db.QueryContext 或其他明确接收 context 的 API；然后确认驱动实现了可取消接口，并通过 rows.Err() 区分查询中断和普通读取结束。

官方地址：https://go.dev/doc/database/cancel-operations

Context 说明：https://go.dev/blog/context

本文只讨论“取消了但下游查询没有停止”的调用链排障，不把取消信号当成数据库事务回滚，也不承诺所有第三方驱动都能在任意时刻强行终止服务器端执行。

先看取消信号有没有走到查询边界

Context 是沿函数调用链传递的值。请求处理器拿到的 r.Context() 被取消后，只有持有这个 context 的下游函数才能观察到 Done() 关闭或 Err() 返回的原因。调用链中间如果把参数换成新的背景 context，父子关系就被切断了。

因此第一轮排查不要先调大数据库超时，而要沿着调用路径确认三件事：处理器是否把 r.Context() 传给服务层；服务层和仓储层是否继续接收同一个 ctx；最终调用是否使用了带 context 的方法。

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    // 请求结束或客户端断开时，r.Context() 会收到取消信号。
    ctx := r.Context()

    // 把同一个 ctx 继续传给业务层，不在中间换成 Background。
    orders, err := h.service.ListOrders(ctx, 42)
    if err != nil {
        // 真实项目中应按 errors.Is 区分取消、超时和数据库错误。
        http.Error(w, err.Error(), http.StatusGatewayTimeout)
        return
    }
    _ = orders // 示例只关注取消信号的传递边界。
}

普通 Query 为什么接不到取消

database/sql 同时提供普通查询和带 context 的查询。db.Query(query, args...) 没有取消参数，即使调用方手里有一个已经结束的 context，它也不会自动影响这次调用。要让查询知道请求的截止时间，必须改用 db.QueryContext(ctx, query, args...)，并且在创建派生 context 后及时调用 cancel 释放计时器资源。

func ListOrders(ctx context.Context, db *sql.DB, userID int64) ([]Order, error) {
    // 调用方已经取消时，避免再向数据库提交新的工作。
    if err := ctx.Err(); err != nil {
        return nil, err
    }

    queryCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel() // 无论成功、超时还是报错，都释放派生 context 的资源。

    rows, err := db.QueryContext(queryCtx, `
        SELECT id, amount
        FROM orders
        WHERE user_id = ?
        ORDER BY id DESC`, userID)
    if err != nil {
        // 这里可能得到 context.Canceled、context.DeadlineExceeded 或驱动错误。
        return nil, err
    }
    defer rows.Close() // 提前返回时也要把 Rows 归还给连接池。

    var orders []Order
    for rows.Next() {
        var item Order
        // Scan 只负责读取当前行，取消状态还要通过 rows.Err() 统一检查。
        if err := rows.Scan(&item.ID, &item.Amount); err != nil {
            return nil, err
        }
        orders = append(orders, item)
    }
    if err := rows.Err(); err != nil {
        // 读取期间发生取消时，错误可能在迭代结束后才暴露在这里。
        return nil, err
    }
    return orders, nil
}

这个改动解决的是“查询 API 没有收到 context”的问题，但不等于所有驱动都能立即停止数据库服务器上的执行。应用层至少要确保超时错误不会被吞掉，连接和 Rows 也不会因为提前返回而长期占用连接池。

驱动能力决定取消能停到哪一层

database/sql 会尝试把 context 交给驱动。如果连接实现了 driver.QueryerContext，驱动应当遵守取消和超时并返回；如果没有实现，database/sql 可能退回到不带 context 的查询路径，这时应用代码虽然写了 QueryContext，底层也未必能及时中断。

排查时可以把现象分成三类：

这里不能把“context 已取消”解释成“数据库中的语句一定已经被杀掉”。它首先表示调用方不再需要结果；驱动是否能把信号转换为协议级取消，要看驱动实现。应用仍应设置合理超时、记录错误，并通过连接池指标观察是否出现长期占用。

几个容易让排查失真的写法

第一，不要在仓储层为了“保证有 context”而写 context.Background()。这只是制造了一个永不取消的根 context，会让上游请求的截止时间失效。第二，不要只在查询开始前调用一次 ctx.Err() 就认为查询可取消；真正执行工作的方法仍然必须接收并使用这个 context。

第三，不要只看 QueryContext 的返回错误。查询已经返回 Rows 后，取消可能发生在迭代过程中，最终状态要检查 rows.Err()。第四，不要把所有取消错误都当成服务端故障：客户端断开、上游超时和本地主动取消都可能是正常控制流，日志中应保留取消原因和请求标识。

可以用下面的顺序快速复查：

1. 从入口确认使用的是请求 context，而不是新建的背景 context。
2. 沿函数参数追到数据库调用，确认每层都传递同一个 ctx。
3. 确认调用的是 QueryContext、ExecContext 或对应的带 context API。
4. 为派生超时调用 cancel，为 Rows 调用 Close，并检查 rows.Err()。
5. 最后查看驱动是否实现 QueryerContext，再判断能否期待及时的底层取消。

常见问题

调用 cancel 后，QueryContext 一定马上返回吗？ 不一定。应用代码会收到取消信号，但具体返回时机受 database/sql、驱动和数据库协议实现影响。

已经使用 QueryContext，为什么连接池还是紧张？ 重点检查是否关闭了 Rows、是否处理了 rows.Err()，以及驱动在取消期间是否仍占用连接。

可以在 DAO 内部直接使用 context.Background 吗？ 对请求链路中的查询通常不应该这样做。应由调用方传入 context；只有真正独立于请求生命周期的后台任务，才应明确创建自己的生命周期。