go 平滑重启失败主因是未屏蔽 sigusr2 传播、未等旧连接关闭完、主 goroutine 过早退出；需用 signal.ignore 防子进程干扰、提前注册 signal.notify、阻塞 main、合理设 shutdown 超时并分层控制 context。
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 或短暂服务不可用。
立即学习“go语言免费学习笔记（深入）”；
- 用
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、以及信号在父子进程间怎么不打架。这些点一旦漏掉，平滑就变成“闪退”。
