Go http.Server.Shutdown 怎么处理在途请求：优雅退出、超时与连接边界

线上接口偶尔会出现一种很难抓的慢请求：用户早已关掉页面，服务端还在继续查库、组装结果，最后把一份没人接收的响应写回去。Go 的 HTTP 请求上下文已经提供了取消信号，但只有把它传到真正耗时的调用里，取消才会产生效果。

先看最小可用的取消处理

在 handler 里直接创建一个新的背景上下文，会切断 HTTP 服务已经建立好的取消链。正确入口是 r.Context()：客户端断开、服务端超时或上游主动取消时，它会被关闭。

func orders(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    rows, err := db.QueryContext(ctx, "SELECT id, amount FROM orders")
    if err != nil {
        if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
            return
        }
        http.Error(w, "query failed", http.StatusInternalServerError)
        return
    }
    defer rows.Close()

    result, err := readOrders(ctx, rows)
    if err != nil {
        if errors.Is(err, context.Canceled) { return }
        http.Error(w, "read failed", http.StatusInternalServerError)
        return
    }
    _ = json.NewEncoder(w).Encode(result)
}

关键点不在于到处判断 ctx.Err()，而是让阻塞调用本身认识这个上下文。一个只在查询结束后才检查取消状态的函数，面对慢 SQL 仍然会占住连接。

把取消信号传到真正耗时的地方

常见的漏点有三类：数据库仍使用不带上下文的方法，内部 HTTP 调用没有绑定请求上下文，以及自建的循环任务只等待定时器。它们都应该把同一个 ctx 往下传。

func readOrders(ctx context.Context, rows *sql.Rows) ([]Order, error) {
    var result []Order
    for rows.Next() {
        var item Order
        if err := rows.Scan(&item.ID, &item.Amount); err != nil { return nil, err }
        select {
        case result = append(result, item):
        case 

内部请求也要使用 http.NewRequestWithContext。如果某个第三方库没有 Context 参数，就要确认它是否提供超时或关闭方法；否则取消只能停掉外层协程，底层工作仍可能继续。

资源释放和响应写入的边界

取消发生后，数据库连接、文件句柄和临时缓冲区仍然需要释放。把 defer rows.Close() 放在资源成功取得之后，通常比在多个错误分支里手写清理更可靠。

不要在取消分支里继续写一大段 JSON。客户端已经断开时，写响应往往只会得到新的网络错误，还会掩盖真正原因。记录一个低级别的取消日志即可；如果响应头尚未发送，才考虑返回简短状态。

测试三个容易混淆的结果

测试时可以用一个可控的查询替代真实慢 SQL：先让函数阻塞，再调用取消函数，最后断言它在限定时间内退出。至少覆盖以下结果：

• 客户端主动断开：返回 context.Canceled，不计入服务端错误率。
• 服务端超时：返回 context.DeadlineExceeded，并检查资源是否释放。
• 真正的数据库错误：保留原始错误并返回 500，不能被统一吞成取消。

如果测试偶尔超时，先看查询驱动是否支持 Context，再看内部 goroutine 是否还在等待无上下文的 channel。单纯把测试等待时间加长，通常只会把泄漏藏得更深。

常见问题

只在 handler 入口判断一次 ctx.Err() 够吗？

不够。入口判断只能挡住已经取消的请求，无法中断后续数据库、网络或循环等待。耗时调用必须接收并使用同一个 Context。

context.Canceled 和 context.DeadlineExceeded 要怎么区分？

前者通常表示调用方主动取消，后者表示截止时间到了。日志、监控和重试策略可以据此做不同处理，但两者都不应当被当作普通业务异常重试。

取消后还需要关闭 rows 吗？

需要。驱动可能会在取消时主动终止查询，但调用方仍应保持明确的资源释放责任，使用 defer rows.Close() 更稳妥。

能不能用 context.Background() 避免请求取消？

只有确实独立于请求的后台任务才适合使用 Background。订单查询、权限校验和响应组装这类请求内工作，应继续沿用请求上下文。

判断 Go HTTP 取消是否真正生效，可以沿着一条链检查：请求上下文是否来自 r.Context()，耗时 API 是否接收它，取消分支是否停止写响应，以及资源是否在每条路径都释放。四处都成立，客户端断开就不会继续消耗一整段后端工作。