用gorilla/websocket连接失败主因是URL协议错误或握手失败；需正确设置ws/wss协议、代理、Header、TLS配置及读写deadline，避免并发写、panic和连接泄漏，并手动实现带退避的重连逻辑。
如何用 gorilla/websocket 连上 WebSocket 服务
连不上基本是握手失败或 URL 错。gorilla/websocket 不自动处理重定向，也不支持 wss:// 时跳过证书校验（除非你显式配置 tls.Config）。
- 确保 URL 是
ws://或wss://开头，不能漏掉协议；http://会直接报dial tcp: lookup http: no such host - 用
websocket.DefaultDialer.Dial()最简单，但生产环境建议传入自定义&websocket.Dialer{Proxy: http.ProxyFromEnvironment}，否则可能被公司代理拦住 - 如果服务端要求带 Cookie 或自定义 Header，必须在 Dial 前构造
http.Header并传进去，Dialer不会读取当前进程的 cookie jar -
wss://下证书错误默认拒绝连接，要跳过验证得写：dialer := &websocket.Dialer{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, }但仅限测试——线上跳过验证等于裸奔
收发消息时怎么避免 panic 和阻塞
gorilla/websocket 的 WriteMessage 和 ReadMessage 默认都是同步阻塞的，且不区分“连接断开”和“写超时”，容易卡死或 panic。
- 永远给连接设
SetReadDeadline和SetWriteDeadline，哪怕只是 30 秒，否则网络卡住时 goroutine 永久挂起 - 不要在同一个连接上并发调用
WriteMessage—— 它不是线程安全的，会 panic 报concurrent write to websocket connection；加锁或用单协程写入 - 读消息建议用
ReadMessage而非ReadJSON，后者在结构体字段类型不匹配时直接 panic，前者只返回[]byte，你来控制反序列化逻辑 - 关闭连接前务必先调用
conn.Close()，否则底层 TCP 可能 linger，服务端收不到 close frame
怎么处理连接中断和自动重连
gorilla/websocket 本身不提供重连逻辑，断连后 ReadMessage 会返回 *websocket.CloseError 或 io.EOF，但不会自动重试。
- 判断是否断连，优先检查 error 是否为
websocket.IsUnexpectedCloseError或errors.Is(err, io.EOF)，别只看字符串含不含 "closed" - 重连前 sleep 几百毫秒（比如 500ms），避免雪崩式重连；指数退避更稳妥，但简单场景用固定间隔够用
- 重连时别复用旧的
*websocket.Conn，它已无效；每次都要重新dialer.Dial() - 如果业务有未发完的消息，重连成功后再补发——但注意服务端是否支持消息去重，否则可能重复消费
gorilla/websocket 和 net/http 的 timeout 设置冲突吗
会。gorilla/websocket 的 Dialer 底层用 net/http.Client 建连，如果你给 http.Client 设了 Timeout，它会覆盖 Dialer.Timeout，导致连接阶段超时行为不可控。
立即学习“go语言免费学习笔记（深入）”；
- 最稳做法：只用
Dialer.Timeout控制建连耗时，别碰http.Client.Timeout - 如果必须用自定义
http.Client（比如要加 trace），请显式设置Transport，并确保Transport.DialContext不引入额外 timeout -
SetReadDeadline/SetWriteDeadline是 per-message 的，和 dial timeout 无关，该设还得设
真正麻烦的从来不是连上那一刻，而是连接中途静默断开、服务端悄悄关掉连接、或者写消息时对方已下线却没及时通知——这些 case 都得靠 deadline + error 类型判断 + 重连状态机兜底，光靠 defer conn.Close() 解决不了问题。
