Go无法真正零停机，必须通过net.Listener.File()导出fd、子进程用net.FileListener恢复、父进程Shutdown等待旧连接结束三者协同；直接ListenAndServe必因端口占用或SO_REUSEPORT调度不均导致connection refused或RST。
Go 无法做到真正意义上的“零停机”发布，但可通过 socket 文件描述符继承 + 进程替换实现接近零中断的平滑重启——关键不在代码多短，而在 fd 是否成功传递、子进程是否正确恢复 listener、旧连接是否被强制中断。
为什么直接 http.ListenAndServe 重启必然中断连接
调用 http.ListenAndServe 会执行 net.Listen("tcp", addr)，而端口已被父进程独占（除非开启 SO_REUSEPORT），新进程启动时立即报错：listen tcp :8080: bind: address already in use。更隐蔽的问题是：即使靠 SO_REUSEPORT 让两个进程同时监听，Linux 内核会把新连接随机分发给任一进程；若父进程已进入 Shutdown 状态但尚未退出，它仍可能收到新连接，却不再 accept，最终返回 connection refused。
- macOS 完全不支持
SO_REUSEPORT，endless 等方案在 macOS 上直接失效 -
SO_REUSEADDR≠SO_REUSEPORT：前者只影响 TIME_WAIT 状态复用，不能解决双进程监听冲突 - 所有基于“新旧进程共 listen 同一地址”的方案，本质都依赖内核调度，无法保证连接不丢
必须用 net.Listener.File() + net.FileListener() 传递 socket
Go 1.8+ 提供了稳定导出和恢复 listener 文件描述符的能力，这是真正复用同一 socket 的唯一可靠路径。父进程拿到 *os.File 后，需通过 os.StartProcess 或 exec.Command 的 ExtraFiles 显式传入，子进程再用 net.FileListener 恢复成可 accept 的 listener。
- 父进程中必须调用
ln.(*net.TCPListener).File()（不能用ln.(net.Listener).File()，类型断言要精确） - 子进程启动时，
ExtraFiles列表索引从 0 开始，但前 3 个（stdin/stdout/stderr）被系统占用，socket fd 应放在索引 3 及之后 - 子进程里恢复 listener 必须在
main()最早位置执行，且不能提前修改os.Stderr或重定向日志，否则os.NewFile(3, "")可能失败 - 验证是否成功：运行中执行
lsof -i :8080，应只看到一个 PID（说明新进程接管了原 socket，旧进程已释放）
facebookgo/grace 为什么比手写更可靠
它把 fd 传递、子进程启动、父进程等待退出封装进 gracehttp.Serve，默认使用 SIGUSR2 触发，并自动处理 FD_CLOEXEC 标志清除——避免子进程启动后 fd 被自动关闭。你不需要手动写 syscall.ForkExec 或管理 ProcAttr.Files。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 监听多个端口（HTTP + HTTPS + metrics）时，必须用
gracehttp.ServeMulti，传入所有*http.Server和对应 listener - 它不依赖
SO_REUSEPORT，而是直接复用父进程的 fd，因此跨平台兼容性更好 - 父进程调用
Shutdown()前，会先停止Accept()，确保新连接全部由子进程处理，旧连接自然完成 - 若服务含 WebSocket，仍需在 handler 中监听
req.Context().Done()并主动关闭 conn，gracehttp不代劳这部分
长连接场景下最容易忽略的三件事
WebSocket、SSE、大文件上传等场景，http.Server.Shutdown() 默认不等待它们结束，因为这些连接已脱离 HTTP 生命周期管理。看似“平滑”，实则大量连接被 RST 强制中断。
- 所有阻塞 I/O 操作（
conn.ReadMessage()、db.QueryRow()、http.Client.Do()）必须使用带context.Context的变体 - WebSocket 升级后，要把
*websocket.Conn存入sync.Map，并在Shutdown()阶段遍历调用Close() -
Shutdown()超时时间不能全局设死；对上传接口建议设 300s，对普通 API 设 30s，用不同 context 分离控制
真正的难点从来不是“怎么让新进程起来”，而是“怎么确认旧连接全都安全结束了”。fd 传递只是起点，连接生命周期闭环才是生产环境不丢数据的底线。
