Golang信号处理与平滑重启教程

本文深入剖析了Go语言中实现真正平滑重启的关键陷阱与实战方案：从SIGUSR2信号被误传播、旧连接未优雅关闭到主goroutine过早退出，逐一拆解三大失败根源；强调必须用signal.Ignore防止子进程干扰、提前注册signal.Notify并阻塞main、分层设计context超时控制（而非硬设5秒）；详解如何安全传递listener文件描述符、正确继承环境变量与工作目录，并指出macOS不支持SIGUSR2等跨平台差异——每一步都直击生产环境“闪退”痛点，帮你把理论上的graceful shutdown变成稳定可靠的线上能力。

Go 里用 signal.Notify 捕获 SIGUSR2 做平滑重启，为什么进程总被直接杀掉？

因为没屏蔽信号传播、没等旧连接关闭完、也没阻塞主 goroutine——三个环节漏一个，SIGUSR2 就变 SIGKILL。

• 必须用 signal.Ignore(syscall.SIGUSR2) 防止子进程（比如 exec.Command 启动的新实例）也收到同个信号，否则新老进程互相干扰
• signal.Notify 的 channel 要在 http.Server.Shutdown 调用前就准备好，否则信号来了却没人收
• 主 goroutine 不能退出：常见错误是监听完信号就 return，导致 main 函数结束，整个进程终止；得用 select {} 或 sync.WaitGroup 卡住
• Linux 下 SIGUSR2 是常用重启信号，但 macOS 不支持该信号用于用户进程（会报 operation not permitted），开发时建议改用 SIGHUP 或 SIGTERM

http.Server.Shutdown 超时设成 5 秒够不够？

不够，取决于你后端依赖和客户端行为。硬设 5 秒大概率会强制断开长轮询、WebSocket 或正在上传的请求。

• 超时时间不是“等 5 秒”，而是“最多等 5 秒，之后调用 Close 强制结束 listener”；真正的连接清理靠 Shutdown 内部的 graceful 逻辑
• 如果业务里有调用外部 HTTP API 或数据库查询，且没设 context timeout，这些 goroutine 可能卡住，导致 Shutdown 永远不返回
• 建议把超时拆成两层：对外暴露的 Shutdown 超时（如 10s），内部所有 handler 都要基于传入的 ctx 做 cancel 控制，比如 http.Client 必须带 ctx，DB 查询必须用 db.QueryContext
• 可加日志观察实际耗时：log.Printf("shutdown took %v", time.Since(start))

用 exec.Command 启新进程时，环境变量和工作目录怎么继承？

默认不继承——新进程只有最基本的 PATH 和 PWD，其他全丢。尤其容易踩坑的是 GOPATH、GOBIN、自定义配置路径。

• Cmd.Env 必须显式赋值：cmd.Env = os.Environ()，否则连 LD_LIBRARY_PATH 这种关键变量都没有
• 工作目录默认是启动时的 os.Getwd()，但如果原进程用 os.Chdir 切过目录，新进程不会同步；稳妥做法是 cmd.Dir = currentDir 显式指定
• 二进制路径别用相对路径：./myapp 在不同 cwd 下会失败；上线时统一用绝对路径，可通过 os.Executable() + filepath.Dir 拼出
• Windows 下注意：exec.Command 启动的进程默认不继承控制台，日志可能看不到；加 cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true} 可选

为什么 net.Listener 文件描述符要从父进程传给子进程？

因为 Linux 的 socket fd 是内核资源，关了就没了。不传递的话，新进程得重新 bind/listen，必然触发 address already in use 或短暂服务不可用。

• 用 listener.File() 获取底层 *os.File，再通过 cmd.ExtraFiles = []*os.File{file} 传进去；子进程用 os.NewFile(uintptr(3), "") 拿回（3 是第一个 ExtraFile 的 fd 编号）
• fd 编号从 3 开始（0/1/2 是 stdin/stdout/stderr），多个 listener 要按顺序对应，错一位就 panic
• 务必在调用 cmd.Start() 前调用 listener.Close()，否则父进程还占着端口，子进程无法接管
• 这个机制只在 Unix-like 系统有效；Windows 没有文件描述符继承概念，得换方案（比如用命名管道或临时端口协商）

真正难的不是写代码，是搞清哪几个 fd 必须传、哪个 ctx 必须 cancel、以及信号在父子进程间怎么不打架。这些点一旦漏掉，平滑就变成“闪退”。

本篇关于《Golang信号处理与平滑重启教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！