gorilla websocket 升级时连接突然断开，是因为 http.server.shutdown() 立即关闭监听套接字却不通知已建立的长连接，客户端收不到 close 帧而被动断连；需配合 shutdown + context.withtimeout、显式设置读写 deadline、主动 close、客户端指数退避重连及反向代理正确透传 upgrade 头，形成三层容错闭环。
gorilla/websocket 升级时连接为何突然断开
因为默认的 http.Server 在调用 Shutdown() 时，会立即关闭监听套接字并拒绝新连接，但已建立的 WebSocket 连接（底层是长生命周期的 TCP 连接）不会被主动通知或优雅终止。客户端收不到 close 帧，只能等读超时或 TCP RST 后被动断连。
用 Shutdown + context.WithTimeout 实现连接等待期
关键不是“不让旧连接死”，而是“给它们留出主动关闭的时间”。必须配合 websocket.Conn.Close() 和读写超时控制：
-
http.Server.Shutdown()需传入带 timeout 的context.Context，比如context.WithTimeout(context.Background(), 30*time.Second) - 在
http.HandlerFunc中，Upgrade 成功后，应立刻设置conn.SetReadDeadline()和conn.SetWriteDeadline()，避免 goroutine 永久阻塞 - 在连接处理循环中，捕获
websocket.IsCloseError(err)或net.ErrClosed，主动调用conn.Close()并退出 goroutine - 不要依赖
defer conn.Close()—— 它在 handler 函数返回时才执行，而此时连接可能早已被Shutdown()强制中断
客户端必须实现重连且带退避逻辑
服务端再优雅，也无法保证所有连接都撑过升级窗口。客户端不重连，用户就卡死。常见错误是简单轮询 setTimeout(() => connect(), 1000)：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用指数退避：初始 1s，失败后 2s → 4s → 8s，上限建议 30s
- 重连前检查
WebSocket.CLOSED或WebSocket.CLOSING状态，避免重复 connect - 记录重连次数，超过阈值（如 5 次）后暂停并提示用户“网络异常”
- 若服务端支持子协议（
Subprotocols），可在重连时带上 session token 或 last-seq-id，用于断线续传
反向代理和负载均衡器必须透传 Upgrade 头
Nginx、Traefik 或 ALB 若未正确配置，会在升级阶段就把连接干掉——这比服务端升级还致命：
- Nginx 必须启用
proxy_http_version 1.1，并显式透传两个头：proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection "upgrade" - AWS ALB 要开启 “WebSockets” 功能（控制台勾选或通过
aws elbv2 set-security-policy-of-listener设置策略） - Kubernetes Ingress 需确认使用的 controller（如 nginx-ingress）版本 ≥ 0.22.0，且 annotation 包含
nginx.ingress.kubernetes.io/ssl-redirect: "true"和nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" - 任何中间件若做 TLS 终止，必须确保它理解 WebSocket 协议升级流程，否则会把
Sec-WebSocket-Key当普通 header 丢弃
真正难的不是写几行 Shutdown()，而是让每个环节都接受“连接终将断开”这个前提，并在服务端等待、客户端重试、网关透传三层上形成容错闭环。漏掉任意一层，零停机就是假象。
