发一次版就冒一串 502，别急着怪 K8s 探针，先看你的关闭顺序

Tue, 21 Jul 2026 09:00:00 +0800

发一次版，监控上就冒出一串 502。

不多，十几个，几秒钟就没了。下一次发版又来一串。你先怀疑的大概是 K8s：是不是 readiness 探针没配好？是不是 terminationGracePeriod 太短？是不是 LB 摘流慢了半拍？

这些方向都不算错，但很多时候真正的问题根本不在编排层。它在你 main 函数最后那几行——收到信号之后，你按什么顺序关掉了这个进程。

graceful shutdown 不是一个函数，是一个顺序

大多数人对优雅关闭的理解，停在这一步：

1
2
3
4


c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
<-c
srv.Shutdown(context.Background())

加了 signal.Notify，加了 srv.Shutdown()，看起来该做的都做了。

但优雅关闭从来不是一个函数调用。它是一整套关闭的先后次序：先停止接收新请求，再等已经进来的请求做完，最后才去关它们依赖的东西——数据库、消息队列、连接池、下游客户端。

这三步的顺序不能乱。

srv.Shutdown() 只负责前两步：它先关掉监听端口，不再 accept 新连接，然后等已经在处理的请求跑完。它管不着你的 DB 连接、你的 Kafka producer、你后台那几个还在写数据的 goroutine。那些是你自己拉起来的，也得你自己按顺序收。

顺序错了，Shutdown 做得再对也白搭。

线上翻车的写法，几乎都长一个样：收到信号，立刻动手关东西。

1
2
3
4


<-c
db.Close() // 先把 DB 关了
srv.Shutdown(ctx) // 再来收 HTTP
os.Exit(0)

或者更干脆，<-c 之后直接 os.Exit(0)，连 Shutdown 都没有。