Go http.Server 关闭时为什么仍有请求挂起

我第一次给 Go HTTP 服务加优雅退出时，最容易误判的是：Shutdown 返回了，进程却没有马上结束；或者 deadline 到了，仍然能看到请求在日志里收尾。原因通常不是方法失效，而是它要等待正在处理的请求回到空闲状态，且不会替你等待被 hijack 的连接。

官方资料：https://pkg.go.dev/net/http

排查“关闭时请求挂起”时，先看连接类型和 handler 是否能结束，再看 Shutdown 的 context deadline。Shutdown 会关闭监听器和空闲连接，但不会强行打断活动请求，也不会接管 WebSocket 这类 hijack 连接。

先分清 Shutdown 到底等待什么

http.Server.Shutdown(ctx) 的行为可以理解成三个静态边界：停止接收新连接、关闭已经空闲的连接、等待活动连接自行回到空闲。只要某个 handler 还在读取请求体、等待下游、持续推送数据，连接就不会被当成已完成。

这也是它和 Close() 的关键区别：Close() 会立即关闭监听器和已知连接；Shutdown 追求不打断正在处理的请求。若传入的 context 先过期，返回值就是 context 的错误，而不是“所有请求都已经完成”。

搭一个可控的优雅退出服务

我更倾向于把服务入口拆成“启动监听”和“等待退出”两块。这样既能把 http.ErrServerClosed 当作正常收尾，也能保证主 goroutine 不会因为 ListenAndServe 返回就提前退出。

package main

import (
	"context"
	"errors"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/slow", func(w http.ResponseWriter, r *http.Request) {
		// 用请求上下文感知客户端断开，避免无意义地继续等待。
		select {
		case 

这段代码里，5 秒只是退出预算，不是让每个请求都自动在 5 秒内完成。请求本身仍应通过 r.Context() 或业务超时控制结束；否则 Shutdown 只能等到 deadline，然后把未完成的请求留在超时分支里。

给长请求和外部连接设置边界

最常见的卡住点在 handler 内部：一个外部调用没有超时、一个流式响应没有结束条件，或者代码在等永远不会到来的 channel。把服务级 Shutdown deadline 和请求级依赖 deadline 分开，问题会容易定位很多。

func callDependency(parent context.Context) error {
	// 下游调用使用更短的预算，不能把整个服务的退出时间耗尽。
	ctx, cancel := context.WithTimeout(parent, 2*time.Second)
	defer cancel()

	select {
	case 

如果服务使用 WebSocket 或手动调用了 Hijack，Shutdown 不会等待这些连接，也不会替它们发送协议级关闭消息。可以用 RegisterOnShutdown 发出“准备关闭”的通知，再由连接管理器单独发送 close、停止读写并等待连接退出。

按现象排查关闭卡住

我通常按下面的顺序看，而不是一看到 Shutdown 超时就把 deadline 无限调大：

还有一个容易遗漏的边界：调用过 Shutdown 的 Server 不能重新复用，后续再次 Serve 会返回 ErrServerClosed。如果部署模型需要重启，应创建新的 Server 实例或直接让进程由 supervisor 拉起。

相关问题

Shutdown 会主动取消正在执行的请求吗？

不会。它等待活动连接变为空闲；业务代码应通过请求上下文、依赖超时和可停止的循环来决定请求何时结束。

为什么关闭监听器后还有新请求日志？

关闭监听器只阻止继续接受新连接，已经进入处理流程的请求仍可能完成；反向代理、连接复用和日志异步写入也会让时间点看起来错开。

应该用 Close 解决所有退出超时吗？

只有确认必须立即切断连接时才考虑 Close。正常发布更适合先用 Shutdown 给请求留出有限退出窗口，超时后再按业务策略处理残留资源。

归根结底，Go http.Server 关闭时请求挂起，通常是“仍有活动请求”或“连接已经脱离 Server 管理”这两类问题。先把状态边界分清，再为 handler、下游调用和 hijack 连接分别设置结束路径，优雅退出才不会变成无限等待。