ReadMessage返回1006错误时必须立即退出读循环并主动关闭连接，不可重试；写操作需设WriteDeadline防阻塞；须用独立goroutine定时ping探测静默断连；重连应指数退避加jitter。
ReadMessage返回websocket: close 1006时必须立即退出读循环
这不是临时错误，而是连接已物理断开的明确信号。继续调用ReadMessage或WriteMessage会触发use of closed network connection panic，或静默卡在写缓冲区。
常见错误现象：日志里反复出现read tcp: use of closed network connection，goroutine 却没退出，连接对象无法被 GC。
- 必须在
for循环内显式检查err != nil，且不能只靠io.EOF判断——1006错误不带io.EOF - 收到该错误后，先调用
conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseGoingAway, ""))主动响应关闭帧 - 再调用
conn.Close()，然后break退出循环，不要continue或重试 - 别依赖
defer conn.Close()—— 它只在函数返回时执行，而读 goroutine 可能长期存活
写操作卡住不报错？SetWriteDeadline是必选项
WriteMessage 在连接已断但内核发送缓冲区还有空间时，会一直阻塞，不返回 error，也不 panic。这是最隐蔽的“假活”状态，导致消息发不出、goroutine 挂起、连接资源泄漏。
常见错误现象：程序没报错，但服务端收不到任何后续消息；pprof 显示大量 goroutine 停在 write 系统调用上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次写前必须调用
conn.SetWriteDeadline(time.Now().Add(10 * time.Second))，超时值建议 5–15 秒 - 不要复用同一个
conn多个 goroutine 并发写——WriteMessage不是线程安全的，必须单 goroutine 串行化，用 channel 转发写请求 - 若
WriteMessage返回i/o timeout或broken pipe，说明连接已不可用，应立刻触发重连，而不是重试写
仅靠ReadMessage错误检测不够，必须主动ping探测
服务端静默断连（如 NAT 超时、负载均衡踢连接、K8s Pod 重启）时，ReadMessage 可能长时间不返回任何 error，客户端持续“假在线”。等真正发消息才发现连不上了。
常见错误现象：客户端页面卡住无响应，但控制台没报错；服务端日志显示连接已掉，客户端却还在心跳计时器里睡大觉。
- 起一个独立 goroutine，每 25–30 秒调用一次
conn.WriteMessage(websocket.PingMessage, nil) - 务必配合
conn.SetPingHandler（默认已注册），否则服务端收不到 pong 会主动断连 -
ping写失败（error 非 nil 或超时）应立即触发重连逻辑，不要等下一次ReadMessage报错 - 避免把 ping goroutine 和读 goroutine 绑定在同一 context 下——读出错退出后，ping 必须还能继续跑几轮确认是否真断
重连失败后指数退避要加 jitter，且首次从1s起步
固定间隔重连（如每次都等 5 秒）会导致多个客户端同步冲击服务端；从 100ms 起步又容易触发雪崩。退避策略必须兼顾收敛速度与系统压力。
常见错误现象：服务端 CPU 突增、连接数暴涨、DNS 解析超时堆积；重连日志显示连续 7 次都在同一秒发起。
- 退避序列建议：1s → 2s → 4s → 8s → 16s → 32s → 60s（封顶）
- 每次重连前加 ±10% 随机偏移（jitter），例如 2s 实际等待 1.8–2.2s
- 用
context.WithTimeout包裹websocket.DefaultDialer.Dial，防 DNS 解析卡死拖慢整个退避节奏 - 连续 5 次失败且已达 60s 间隔时，可降级为轮询 HTTP 接口，避免彻底失联
真实连接状态永远藏在 I/O 行为里，不是靠 conn.IsClosed() 或心跳定时器是否运行来判断的。每次读写都是一次探针，而你写的每一行 error 检查，都在决定这个连接是“死透了”，还是“还能抢救一下”。
