服务器关闭时长连接没有退出怎么办

Go 服务器关闭时长连接没有退出，通常不是 http.Server.Shutdown 失效，而是关闭流程里仍有活跃 handler、流式响应，或者已经被 hijack 的连接。我的经验是先把连接分成三类：普通 HTTP 请求由 Shutdown 等它回到空闲；长轮询和流式处理需要应用代码主动收尾；WebSocket 等 hijack 连接则完全由业务自己通知和关闭。

先区分 Shutdown 正在等待哪类连接

官方语义里，Shutdown 先关闭监听器，再关闭空闲连接，然后等待活跃连接变回空闲。也就是说，keep-alive 空闲连接一般不会成为真正的阻塞点；一直不返回的 handler、持续写出的流式响应和长轮询才会让关闭上下文超时。Server.Close 更强硬，会立即关闭服务器管理的连接，但它也不知道 hijack 之后的连接。

排查时可以用 ConnState 记录状态变化。StateActive 代表连接上还有请求处理，StateIdle 代表请求已经完成、等待下一个请求；如果服务一直卡在 active，优先回到 handler 的退出条件，而不是反复调用 Close。

让主 goroutine 真正等待 Shutdown 返回

ListenAndServe 因为关闭监听器而返回 http.ErrServerClosed 是正常现象。常见错误是把启动函数放在 goroutine 中，收到信号后调用 Shutdown，但主函数没有等待结果，导致进程先退出，读者误以为长连接没有完成清理。

package main

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

func main() {
	srv := &http.Server{Addr: ":8080", Handler: http.DefaultServeMux}

	go func() {
		// ErrServerClosed 表示主动关闭，不应被当成启动故障。
		if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
			log.Printf("HTTP server error: %v", err)
		}
	}()

	stopCtx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
	defer stop() // 释放信号监听资源。
	

这里的关键不是 10 秒这个数字，而是生命周期顺序：收到信号后停止接收新连接，等待现有 handler 自己结束，再让进程退出。生产环境应根据最长业务请求、部署平台的终止宽限期和长连接策略调整超时。

让长轮询和流式处理增加停止信号

长轮询 handler 可能在等待消息，流式 handler 可能在循环写数据。仅调用 Shutdown 不会替你设计业务循环的退出条件。我的做法是给这类 handler 一个进程级停止通道，同时保留请求上下文：客户端先断开时由 Request.Context 结束，服务发布时由停止通道结束。

var (
	stopCh   = make(chan struct{})
	stopOnce sync.Once
)

func longPoll(w http.ResponseWriter, r *http.Request) {
	ticker := time.NewTicker(2 * time.Second)
	defer ticker.Stop() // handler 退出时释放 ticker。

	for {
		select {
		case 

示例省略了导入列表和路由注册，重点是两个取消来源都必须进入同一个 select。可以在调用 Shutdown 前先执行 notifyHandlers，也可以把它注册到 RegisterOnShutdown；如果回调里需要等待 handler，请把等待放在回调外，因为官方要求回调启动协议级关闭，不要阻塞 Shutdown 自己的收尾。

单独处理 WebSocket 等 hijack 连接

一旦 handler 通过 Hijacker 接管连接，HTTP server 就不再负责后续生命周期。Shutdown 不会等待它，Close 也不知道它，因此“HTTP 请求都结束了但进程仍有连接”并不矛盾。

这类连接应在业务层维护连接集合：建立连接时登记，正常断开和读写错误时移除；关闭开始时发送协议允许的关闭通知，再关闭或等待连接。RegisterOnShutdown 适合触发这件事，但回调应快速返回，不能在其中同步等待所有 WebSocket。需要等待时，使用独立的 sync.WaitGroup 或关闭完成 channel，并把它放在外层的 shutdown 编排里。

为关闭过程设置超时和可观察状态

建议把“卡住”拆成可记录的事实，而不是只打印一句 shutdown timeout：

如果优雅关闭超过宽限期，记录 Shutdown 返回的上下文错误；是否追加 Server.Close 要由业务决定，因为它会打断服务器管理的活动连接，仍然不能替你清理 hijack 连接。修复后应重点看 handler 是否都能在停止信号下返回，而不是只看进程最终有没有消失。

常见问题

为什么调用 Shutdown 后，长轮询请求还没有马上断开？

这是预期行为。Shutdown 会尽量不打断活跃连接，长轮询必须自己监听停止通道或请求上下文并返回；如果它仍在阻塞等待，Shutdown 就会继续等待到上下文超时。

把 Shutdown 换成 Close 就一定能解决吗？

不一定。Close 会更快关闭服务器管理的连接，但会中断活跃请求，而且对 hijack 后的连接仍然无能为力。只有明确接受中断语义时，才把它作为超时后的兜底动作。

参考资料：Go net/http 官方文档 https://pkg.go.dev/net/http 与服务器实现 https://go.dev/src/net/http/server.go。