根本原因是go进程重启导致tcp连接被内核强制回收，真正的平滑升级需旧进程继续服务存量websocket连接直至自然关闭或优雅终止，并配合nginx透传upgrade头、客户端心跳+指数退避重连及全链路超时协同。
gorilla/websocket 服务在升级时断连，根本原因不是库本身的问题，而是 Go 进程重启导致连接 fd 被内核回收，且没有给已建立的 WebSocket 连接留出关闭窗口。只要进程退出，所有 TCP 连接（包括 WebSocket）必然断开——这是操作系统行为，无法绕过。真正的平滑升级，必须让旧进程继续处理存量连接，直到它们自然结束或被主动优雅关闭。
Go 进程热重启需 fork + 文件描述符传递
标准 http.Server.Shutdown() 只能停止新请求接入，但无法保留旧连接的生命周期控制权。要实现真正零中断，必须用 Unix 域套接字或 net.Listener 文件描述符继承方式，让新进程接管监听端口，同时旧进程继续服务已有连接。
- 使用
github.com/freddierice/go-restart或github.com/alexedwards/overlord等库可简化 fork 流程 - 关键步骤：旧进程调用
syscall.Dup()复制 listener fd → 通过exec.Cmd.ExtraFiles传给新进程 → 新进程用net.FileListener恢复监听 - 旧进程不能立即退出，需等待所有
*websocket.Conn调用Close()或超时（如设置WriteDeadline后发 close frame）
gorilla/websocket 必须启用 SetCloseHandler + SetReadDeadline
默认情况下，gorilla/websocket 在连接断开时不会触发自定义逻辑，也无法感知对端是否已关闭。若不显式设置，旧进程即使收到 SIGTERM，也无法向客户端发送规范的 close frame，浏览器会报 WebSocket is closed before the connection is established 或直接卡在 CLOSING 状态。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
conn.SetCloseHandler()：捕获对端发起的关闭帧，可在此清理资源、广播下线事件 -
conn.SetReadDeadline(time.Now().Add(30 * time.Second))：配合SetPongHandler实现心跳保活，避免连接被中间设备静默 kill - 务必在
Upgrade后立即设置，否则早期读操作可能 panic 或阻塞
Nginx 反向代理必须透传 Upgrade 头且禁用缓冲
即便 Go 进程热重启成功，如果前端 Nginx 配置错误，WebSocket 握手阶段就会失败，表现为 502 或连接瞬间关闭。这不是 Go 层能解决的问题。
- 必须在
location块中写死这三行：proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"、proxy_http_version 1.1 -
proxy_buffering off：WebSocket 是流式协议，缓冲会导致帧粘包或延迟，尤其影响 ping/pong 时序 -
proxy_read_timeout 86400和proxy_send_timeout 86400：防止 Nginx 主动断开空闲连接（云厂商 LB 通常有更短的默认值，需同步调整）
客户端重连不能只靠 onclose，要结合心跳失败兜底
浏览器原生 WebSocket.onclose 事件不可靠：网络闪断、NAT 超时、防火墙拦截时，该事件可能延迟数秒甚至不触发。仅依赖它启动重连，用户会长时间处于“假在线”状态。
- 客户端应独立维护心跳计时器（如每 30 秒
ws.send("ping")），超时未收到响应即判定断连 - 重连间隔必须指数退避（1s → 2s → 4s → 8s），避免雪崩式重连压垮新实例
- 重连时带上上次连接的 session ID 或 token，服务端可快速恢复上下文，避免重复登录或消息丢失
真正的难点不在代码量，而在于各层超时参数的协同：Nginx 的 proxy_read_timeout、Go 的 SetReadDeadline、客户端心跳间隔、重连退避上限——它们必须构成一个严格嵌套的超时链，任何一环松动，都会导致连接卡死或误判。生产环境上线前，务必用 tcpdump 抓包验证 close frame 是否真实发出，而不是只看日志里有没有 “connection closed” 字样。
