Go标准库不支持WebSocket，因缺乏帧解析、心跳管理及消息读写能力；必须用gorilla/websocket等第三方库，通过upgrader.Upgrade()获取*websocket.Conn才能通信。
gorilla/websocket 是唯一可行的选择，Go 标准库不提供 WebSocket 帧解析、心跳管理或消息读写能力。试图用 net/http 手动处理 101 Switching Protocols 或自己拼接 WebSocket 帧，必然导致客户端报 Invalid frame header 或连接立即中断。
为什么不能用标准库直接 dial 或 serve WebSocket
标准库的 http.ServeMux 和 http.ResponseWriter 仅支持 HTTP 协议语义，无法识别或生成 WebSocket 的二进制帧、掩码、opcode、Ping/Pong 控制帧等。升级请求后若继续往 w 写入任何内容（哪怕一个空格），就会触发 http: response.WriteHeader on hijacked connection 错误。
-
http.ListenAndServe只能启动 HTTP 服务，不能“自动升级”为 WebSocket - 没有
websocket.Dial、websocket.Conn.ReadMessage等核心函数，必须依赖第三方实现 - 社区已归档的
code.google.com/p/go.net/websocket不再维护，且不兼容现代浏览器握手
服务端必须显式调用 upgrader.Upgrade()
WebSocket 连接不是“配置好路由就通了”，而是由 handler 显式完成协议切换。关键点在于：upgrader.Upgrade() 返回的 *websocket.Conn 才是真正可用的通信句柄，原 http.ResponseWriter 和 *http.Request 在调用后即失效。
- 必须在
Upgrade()前禁止任何响应写入（包括log.Print意外 flush 到w） -
CheckOrigin默认拒绝非同源请求；开发时可设为func(r *http.Request) bool { return true }，但生产环境务必校验r.Header.Get("Origin") - 升级后立即
defer conn.Close()，避免 goroutine 泄漏
客户端连接要处理超时与重连逻辑
直接用 websocket.DefaultDialer.Dial(wsurl, nil) 会阻塞直到 TCP 握手完成，而 DNS 解析、TLS 握手、代理延迟都可能导致数秒甚至更久无响应。没有超时控制的客户端在服务不可达时会卡死。
立即学习“go语言免费学习笔记（深入）”；
- 应使用自定义
&websocket.Dialer{Timeout: 5 * time.Second} - 连接失败后不要立即重试旧地址——尤其当服务走内网穿透（如 cpolar、frp）时，地址可能已过期
- 建议封装
connectWithBackoff()：首次失败后等待 1s，后续按指数退避（2s、4s、8s…），上限 30s - 每次重连前检查是否需要刷新地址（例如 GET
/api/ws-endpoint获取最新ws://...）
ReadMessage 和 WriteMessage 的隐含行为
这两个方法看似简单，但底层有重要约束：它们默认使用阻塞 I/O，且 WriteMessage 不保证原子发送（大消息可能被拆帧），ReadMessage 会一次性读完一整帧，不会返回部分数据。
- 不要在同一个
*websocket.Conn上并发调用WriteMessage—— 它不是 goroutine-safe，需加锁或用单 writer goroutine - 读循环中遇到
websocket.CloseMessage类型应主动调用conn.WriteMessage(websocket.CloseMessage, nil)回复关闭帧，再退出 - 若需发送 > 1MB 消息，考虑用
conn.WriteControl发送 Ping 或分片，否则可能触发websocket: write deadline exceeded
真正难的不是连上，而是连得稳：连接建立只是起点，超时判断、错误分类（网络断开 vs 协议错误 vs 对端静默）、重连时的状态同步（如重新订阅 topic）、以及多连接下的资源回收，这些才是线上 WebSocket 服务崩塌的常见原因。
