Golang结合Fiber框架如何做优雅关机？服务平滑重启方案-Golang-PHP中文网

Fiber的app.Shutdown()无法真正优雅关机，因其仅调用底层http.Server.Shutdown()，但未内置信号监听、未传播超时context至handler、未管理listener生命周期，导致WebSocket/SSE等长连接被强制中断，必须手动补全信号监听、带超时context及主动关闭长连接三要素。

golang结合fiber框架如何做优雅关机？服务平滑重启方案

为什么直接用 `Fiber.App.Shutdown()` 会丢请求

很多人以为调 app.Shutdown() 就算优雅关机了，其实它只是个空壳——Fiber 没有内置信号监听、不管理 listener 生命周期、也不自动传播 context 到 handler。现象很典型：Ctrl+C 一按，正在上传的大文件中断、WebSocket 连接立刻报 connection reset by peer、客户端收到空响应或 502。根本原因是 app.Shutdown() 只是调用了底层 http.Server.Shutdown()，但没配套信号注册和上下文控制，等于只装了刹车片，没配刹车油和刹车踏板。

必须手动补全的三块拼图：信号 + context + listener

真正不丢请求的关机，得靠这三者协同：

用 signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM) 监听信号，别漏 SIGTERM（systemd 默认发这个，不是 SIGHUP）
超时 context 必须干净：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)；别 defer cancel()，否则 Shutdown() 还没开始就超时了
app.Server().Shutdown() 要传这个 ctx；同时确保所有 handler 里用了带 ctx 的阻塞操作，比如 db.QueryContext(ctx, ...)、client.Do(req.WithContext(ctx))

Fiber 中长连接（WebSocket/SSE）怎么不被 Shutdown 中断

http.Server.Shutdown() 对已升级的连接完全无感知。Fiber 本身不接管 WebSocket 生命周期，所以你得自己管：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

在 app.Get("/ws", func(c *fiber.Ctx) error { ... }) 里，拿到 c.Context() 后立刻存进全局 sync.Map，key 是 conn ID 或 remote addr
收到关机信号后，在 app.Shutdown() 前，遍历 map 主动调 conn.Close() 或设 conn.SetReadDeadline(time.Now())
SSE handler 里不能只写 c.SendString("data: ...")，每次写前加 select { case
避免在中间件里起异步 goroutine（比如日志上报），除非它也监听同一个 c.Context().Done()

平滑重启时 socket fd 怎么安全传给新进程

Fiber 没封装 fd 复用逻辑，得手动做。Linux 下唯一可靠方式是通过 exec.Cmd.ExtraFiles 传递：

老进程收到 SIGUSR2 后，从 app.Server().Listener 提取 *net.TCPListener，再调 .File() 得到 *os.File，记下 file.Fd()（通常是 3）
启动子进程时，cmd.ExtraFiles = []*os.File{os.Stdin, os.Stdout, os.Stderr, file}
新进程启动后第一行代码：用 os.NewFile(3, "") 恢复句柄，再 net.FileListener(file) 转成 net.Listener
app.Server().Addr 必须设为空字符串 ""，否则 app.Listen() 会尝试重新 bind，报 address already in use