WebSocket连接建立失败的常见握手错误包括：一、客户端未发送Origin头（如file://打开页面）；二、服务端CheckOrigin函数未正确配置，默认拒绝跨域；三、浏览器Network中状态码为400/500且缺失Sec-WebSocket-Accept响应头；四、反向代理未透传Upgrade和Connection头；五、SSL证书无效或子协议不匹配。
WebSocket连接建立失败：常见握手错误怎么定位
Go 的 gorilla/websocket 库在升级 HTTP 连接时，如果客户端发来的请求头不合规，会直接返回 400 或 500，但默认不暴露具体原因。最常踩的坑是前端没带 Origin 头（尤其本地 file:// 打开页面），或服务端没正确设置 CheckOrigin 函数。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先在服务端加一行日志：
log.Printf("origin: %s, header: %+v", r.Header.Get("Origin"), r.Header)，确认客户端是否真发了 Origin - 开发阶段直接放行所有 Origin：
upgrader.CheckOrigin = func(r *http.Request) bool { return true }，上线前再改回严格校验 - 浏览器控制台 Network 标签页里点 WebSocket 请求，看 Status 是不是 400/500，Response Headers 里有没有
Sec-WebSocket-Accept—— 没这个字段说明握手根本没走完
并发写入 panic：为什么 conn.WriteMessage() 会报 “write tcp: use of closed network connection”
WebSocket 连接不是线程安全的，conn.WriteMessage() 和 conn.ReadMessage() 不能同时从多个 goroutine 调用。典型场景是：一个 goroutine 在广播消息，另一个在处理用户断开后的清理逻辑，结果广播时 conn 已被关闭。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给每个连接配一个带缓冲的
chan []byte（比如send chan []byte），只允许一个 goroutine 从该 channel 读并调用WriteMessage - 读消息的 goroutine 收到
websocket.CloseMessage后，先 close(send)，再 return，避免后续广播往已关闭的 channel 发送 - 广播前检查 conn 是否还活着：
if conn == nil || conn.IsClosed() { continue }—— 注意IsClosed()是 gorilla v1.5.0+ 才有，旧版本得靠conn.WriteMessage(websocket.PingMessage, nil)探活
消息广播性能卡在 100 人以内：为什么用 map 存连接比用 slice 快
当房间人数上升，遍历所有连接广播消息时，如果用 []*websocket.Conn 存储，每次都要复制整个 slice；而用 map[string]*websocket.Conn（key 是用户 ID）能 O(1) 查找、O(n) 广播，且增删都是常数时间，GC 压力更小。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要用
sync.Map存连接 —— 它适合读多写少，而聊天室连接频繁增删，普通map+sync.RWMutex更稳 - 广播时别用
for range直接遍历 map，先用connList := make([]*websocket.Conn, 0, len(clients))提前分配容量，再 append，避免多次扩容 - 如果单房间超 500 人，考虑把广播拆成多个 goroutine 分片处理，但分片数别超过 GOMAXPROCS，否则调度开销反升
客户端收不到消息：为什么 conn.SetReadDeadline() 影响不大，但 conn.SetWriteDeadline() 很关键
ReadDeadline 主要防客户端假死占用 goroutine；WriteDeadline 才真正决定消息能否发出去。如果网络抖动或客户端卡住，WriteMessage() 可能阻塞几秒甚至几十秒，导致后续消息积压、goroutine 泄露。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须在每次
WriteMessage()前设 WriteDeadline：conn.SetWriteDeadline(time.Now().Add(10 * time.Second)) - 捕获
net.ErrTimeout和websocket.ErrCloseSent，前者重试 1 次，后者直接关连接 - 不要全局设 WriteDeadline —— 它只对下一次写生效，设一次就覆盖了，必须每次写前重设
真实场景里，连接断开往往发生在写环节，而不是读环节。很多人只设 ReadDeadline，结果广播卡住、goroutine 堆积、内存暴涨，最后才发现是 WriteDeadline 漏了。
