recover仅能捕获panic防止goroutine崩溃，无法维持WebSocket连接；真正保活需依赖deadline设置、ping/pong心跳及对I/O error的主动处理。
recover 不能维持 WebSocket 连接，只能防止 goroutine 崩溃
很多人以为在 WebSocket handler 里加 defer recover() 就能让连接“不断开”，这是根本性误解。recover 的作用仅限于捕获 panic、阻止当前 goroutine 终止，并**不恢复网络连接状态**。一旦底层 *websocket.Conn 因读写错误、超时、客户端断网而失效，recover() 完全无能为力——它既不重连，也不心跳，更不重置连接。
真正决定连接是否存活的，是 conn.ReadMessage() 和 conn.WriteMessage() 的返回值、deadline 设置、以及你是否主动调用 conn.Close()。recover 只在这些操作触发 panic（比如并发写）时起兜底作用，而非连接保活机制。
必须在每个读/写协程里单独 defer+recover
gorilla/websocket 要求每个连接配独立读协程和写协程；而 panic 可能发生在任一协程中（如 map 并发读写、nil 解引用、JSON 解析失败）。若只在 handler 入口 recover，读协程 panic 后会直接退出，连接变成“半死”：客户端收不到消息，服务端也收不到新帧，但 TCP 连接还挂着。
- 读协程开头必须有：
defer func() { if r := recover(); r != nil { log.Printf("read panic: %v", r); conn.Close() } }() - 写协程同理，且要额外检查
conn.WriteMessage()返回的 error，不能只靠 recover - 禁止在广播循环里直接调
conn.WriteMessage()—— 一旦某个 conn 已关闭或卡住，会 panic 并终止整个广播 goroutine - 第三方库如
gobreaker或hystrix-go的DoC包装器内部已含 recover，可复用，但别误用Do（它不 recover）
recover 后必须显式关闭连接并清理资源
recover 捕获 panic 后若只是打印日志然后继续运行，极易导致资源泄漏：goroutine 不退出、channel 不关闭、sync.Map 里的连接句柄不删除。此时连接看似“还在”，实则已无法通信，成为僵尸连接。
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
- recover 块内应立即调用
conn.Close()，并关闭该连接专属的readCh/writeCh - 从房间的
clients sync.Map中删除该*websocket.Conn，否则下次广播仍会尝试向已关闭连接写入，再次 panic - 不要用
os.Exit()或panic()终止 recover 块，这会让整个进程退出，k8s 会反复拉起实例 - 若使用
sync.WaitGroup管理协程生命周期，recover 后需调用wg.Done()，否则主逻辑可能永远等不到协程退出
真正维持长连接靠的是 deadline + 心跳 + 主动错误处理
recover 是“防崩”，不是“保活”。WebSocket 长连接稳定的核心是三件事：设好读写 deadline、实现 ping/pong 心跳、对 I/O error 做明确响应。这三者缺一不可，且都与 recover 无关。
-
conn.SetReadDeadline(time.Now().Add(30 * time.Second))必须在每次ReadMessage()前设置，否则一次网络抖动就永久阻塞读协程 - 启用
conn.SetPingHandler()并配合conn.SetPongHandler()，服务端收到 pong 后重置 deadline，客户端超时未 pong 则主动 close - 所有
ReadMessage()和WriteMessage()的 error 都要判断：if errors.Is(err, websocket.ErrCloseSent)或strings.Contains(err.Error(), "use of closed network connection")，匹配后立即退出协程并清理 - 客户端断连时，
ReadMessage()通常返回io.EOF或websocket.CloseMessage，这不是 panic，recover 根本不会触发——你得靠 error 判断
recover 在 WebSocket 场景里唯一合理的角色，是兜住那些本不该发生但又难以完全规避的编程错误（如未加锁访问共享 map、未判空解引用），避免单个连接异常拖垮整个服务。它不替代连接管理逻辑，也不提供任何保活能力。把 recover 当成“连接永生术”，只会让问题更隐蔽、更难排查。
