Buffalo 不支持内置滚动更新，零停机发布依赖外部进程管理（如tableflip）、Go信号处理（SIGUSR2）和Nginx反代配合（proxy_http_version 1.1等），缺一不可。
Buffalo 是一个面向 Go 的全栈 Web 框架，本身**不内置滚动更新能力**——它没有类似 Kubernetes Deployment 的编排层，也不管理多实例生命周期。所谓“零停机平滑发布”，实际依赖的是**外部进程管理 + Go 原生信号支持 + 反向代理配合**，而非框架自身功能。
下面分三块说清楚怎么做、为什么这么设计、以及最容易翻车的地方。
Go 服务如何响应 SIGHUP 实现优雅重启
Buffalo 应用本质是 Go 程序，靠 http.Server 启动。要支持平滑更新，必须自己实现或借助库处理 SIGHUP（重载配置）或 SIGUSR2（热升级），主流做法是用 fvbock/endless 或更现代的 cloudflare/tableflip。
-
endless已停止维护，不建议新项目使用；tableflip更轻量、无 fork、兼容 systemd，推荐 - 关键逻辑：旧进程继续处理未完成请求，新进程启动并监听同一端口（需
SO_REUSEPORT），握手成功后旧进程退出 -
Buffalo启动代码需包裹在tableflip的Upgrader.Upgrade()回调中，不能直接调app.Serve() - 注意：数据库连接、Redis 客户端等全局资源必须在新进程中重新初始化，不能复用旧进程句柄
Nginx 反向代理必须启用 proxy_http_version 1.1 和连接保持
即使 Go 进程能优雅切换，如果前端反代不配合，用户仍会看到 502 Bad Gateway 或连接中断。Nginx 默认使用 HTTP/1.0 转发，不保持长连接，导致 upgrade 过程中 worker 关闭时活跃连接被粗暴终止。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 必须在 upstream 配置里显式开启：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 建议加
proxy_buffering off;避免 Nginx 缓存响应体干扰流式响应（如 SSE、WebSocket） - 健康检查路径（如
/healthz）要返回 200 且不依赖 DB，否则新进程还没 ready 就被 LB 切入流量
部署脚本必须避免直接 kill -9 或覆盖二进制文件
很多团队用简单 shell 脚本更新：先 killall buffalo，再 cp new-binary ./buffalo —— 这完全破坏平滑性。
- 正确流程：新二进制启动后，通过 IPC 或文件锁通知旧进程开始
Shutdown()；等待http.Server.Shutdown()返回才退出 - 不要覆盖正在运行的二进制文件（Linux 允许但极危险）：旧进程可能因 mmap 失效 panic，或新旧版本符号冲突
- 推荐方案：每次部署生成带版本号的二进制（如
buffalo-v1.2.3），用 systemd 管理，通过ExecReload触发SIGHUP - 验证是否生效：部署中执行
ss -tlnp | grep :3000，应短暂出现两个 PID；再查curl -I http://localhost/healthz是否全程 200
真正难的不是写几行 Go 代码，而是让所有环节——从进程信号、socket 复用、反代配置、到部署动作——形成闭环。漏掉任意一环，比如忘了 Nginx 的 Connection 头，就会在高并发下暴露几十毫秒的请求失败窗口。这个窗口不会报错，但日志里会有孤立的超时记录，很难归因。
