WebSocket连接易断因ResponseWriter复用；并发写需深拷贝缓冲区；掉线需心跳+超时检测；广播应无锁快照+限并发；生命周期管理是关键。
WebSocket 连接建立后立刻断开？检查 http.ResponseWriter 是否被复用
Go 的 http.ServeHTTP 要求每个请求只能写一次响应头，而 WebSocket 升级过程依赖 response.Header().Set("Upgrade", "websocket") 和 response.WriteHeader(101)。一旦你在这之后又调用了 response.Write()（比如日志中间件、模板渲染、或误加的 fmt.Fprintf(response, ...)），连接就会在握手完成前被强制关闭。
- 确保升级路径是独立的 HTTP 处理函数，不混用 HTML 渲染逻辑
- 用
gorilla/websocket时，必须用upgrader.Upgrade(response, request, nil)，不要自己手动写状态码和 header - 调试时抓包看响应是否含
HTTP/1.1 101 Switching Protocols，若出现200 OK或直接无响应，基本就是 response 被提前消费了
多个客户端发消息收不到？别直接往 conn.WriteMessage() 里塞共享切片
WebSocket 消息发送不是原子操作，conn.WriteMessage() 底层会复用传入的 []byte 缓冲区。如果多个 goroutine 并发往同一个连接写，或者反复复用一个全局 buf 变量（比如 json.Marshal 后没拷贝就传给 WriteMessage），会出现消息错乱、截断甚至 panic。
- 每次发送前都用
append([]byte(nil), data...)或bytes.Copy做一次深拷贝 - 更稳妥的做法：用
json.Marshal返回新切片，不缓存结果；或为每个连接配一个sync.Pool管理临时 buffer - 避免在广播循环中直接传入未隔离的数据引用，例如：
for _, c := range clients { c.conn.WriteMessage(..., msg) }中的msg必须是每次迭代独立构造的
客户端突然掉线，服务端没感知？别只靠 ReadMessage() 的 error 判断
conn.ReadMessage() 在网络中断、客户端崩溃、NAT 超时等场景下，往往不会立即返回 error，而是长时间阻塞，或返回 io.EOF / websocket.CloseMessage 但已滞后数秒甚至分钟。这会导致服务端堆积大量“僵尸连接”，无法及时清理。
- 必须设置读写超时：
conn.SetReadDeadline(time.Now().Add(30 * time.Second))，并在每次ReadMessage()前重置 - 启用心跳机制：用
conn.SetPingHandler()处理客户端 ping，同时定期用conn.WriteMessage(websocket.PingMessage, nil)主动探测 - 注意
net/http默认的 idle timeout 是 30 秒，若反向代理（如 Nginx）也设了短超时，需同步调大，否则连接会在应用层感知前被中间件切断
并发广播性能卡在 100 连接左右？别用锁保护整个 client map
常见写法是用 sync.RWMutex 包裹所有 clients 读写，但广播时要遍历全部连接并调用 WriteMessage() —— 这个操作本身可能阻塞（尤其网络慢时），导致锁持有时间过长，后续新连接注册、消息入队全被堵住。
立即学习“go语言免费学习笔记（深入）”；
- 改用无锁结构：把
clients存成map[uint64]*Client，增删用sync.Map；广播时不锁 map，而是先用LoadAll快照一份活跃连接列表再异步发 - 每个连接单独起 goroutine 发送，但限制并发数（比如用带缓冲的 channel 控制最多 10 个并发写），防止单次广播压垮系统
- 真正影响吞吐的是写缓冲区积压，可调
conn.SetWriteBuffer(64 * 1024)提升批量能力，但别超过 OS socket buffer 上限
最麻烦的从来不是连上 WebSocket，而是连接生命周期管理——什么时候关、谁来关、关了之后数据还剩多少、重连时状态怎么续。这些细节藏在 Close 调用顺序、error 类型判断、以及超时与心跳的配合节奏里，少对一环，聊天室就变成“半双工收音机”。
