根本原因是向已关闭的 websocket 连接写数据；应通过读协程监听 EOF/CloseMessage 并关闭连接，写操作改用带缓冲 channel + 专属写协程，广播时非阻塞发送并丢弃满载消息。
为什么 gorilla/websocket 的 WriteMessage 会 panic: "write tcp: use of closed network connection"
这是最常遇到的崩溃，根本原因不是写操作本身出错，而是连接早已被对端关闭或服务端主动 Close 后，还试图往已关闭的 *websocket.Conn 写数据。
典型场景：客户端断网、刷新页面、浏览器标签页关闭后未触发 onclose，服务端却还在用旧连接推送；或者多个 goroutine 并发调用 WriteMessage，但没做连接状态同步。
- 每次调用
WriteMessage前，先检查conn.RemoteAddr() != nil不可靠，应改用conn.WriteDeadline配合net.ErrClosed判断 - 更稳妥的做法是：在读协程中监听
conn.ReadMessage()返回的io.EOF或websocket.CloseMessage，一捕获就立刻调用conn.Close()，并通知写协程退出 - 不要复用
*websocket.Conn跨 goroutine 写 —— 每个连接建议配一个专属的写协程 + channel（如chan []byte），由它统一处理发送和错误退出
如何安全地向多个客户端广播消息而不阻塞主逻辑
直接遍历所有 *websocket.Conn 并调用 WriteMessage 是危险的：某个慢连接或已断开的连接会让整个广播卡住，拖垮其他用户。
核心思路是把“推送”变成非阻塞、可丢弃的异步操作，同时避免为每个连接起 goroutine（连接数多时 GC 和调度压力大）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 给每个连接维护一个带缓冲的
chan []byte（比如 buffer size = 16），写协程从该 channel 读取消息并发送 - 广播时只往每个 client 的 channel 发送，若 channel 满（说明该连接写不过来），直接
select { case ch 丢弃，不阻塞 - 务必设置
conn.SetWriteDeadline，例如time.Now().Add(5 * time.Second)，否则网络卡顿时写协程会永久挂起 - 别用全局 map 存连接 —— 用
sync.Map或加读写锁，尤其在增删连接（Upgrade/Close）时避免并发 panic
Upgrader.CheckOrigin 怎么设才既防 CSRF 又不误杀合法请求
默认拒绝所有跨域，但生产环境前端往往部署在不同域名（https://app.example.com）甚至子路径，硬写死 origin 容易导致连不上，而设成 func(r *http.Request) bool { return true } 又等于裸奔。
- 最简安全做法：只允许已知前端域名，用
strings.HasSuffix(r.Header.Get("Origin"), ".yourdomain.com")，比完整匹配更灵活（适配 dev/staging 环境） - 如果用 Nginx 反向代理，注意
Origin头可能被 strip，需在 proxy 配置里显式透传：proxy_set_header Origin $http_origin; - 开发阶段可在本地加临时白名单：
if r.Header.Get("Origin") == "http://localhost:3000" { return true }，上线前删掉 - 千万别依赖
Referer校验 —— 它不可靠、易伪造，且现代浏览器在跨域时可能不带
为什么用 gorilla/websocket 而不用标准库 net/http 自己实现握手
标准库能完成 WebSocket 握手（ResponseWriter + 手动写 header），但后续帧解析、掩码处理、ping/pong 心跳、错误恢复全是硬骨头。
gorilla/websocket 不只是封装，它把 RFC 6455 的边界情况都踩过坑：比如客户端不按规范发 unmasked frame、分片消息乱序、控制帧插入数据帧中间等。
- 它内置了
conn.SetPongHandler自动响应 ping，省得自己解析控制帧；而手动实现容易漏掉PingMessage导致连接被客户端单方面断开 - 它的
WriteJSON自动处理 struct tag 和 error 包装，比json.Marshal+WriteMessage少三层 if-check - 性能上无明显劣势 —— 关键路径已用
unsafe和预分配 buffer 优化，实测 1k 连接下吞吐与 hand-rolled 版本基本持平
真正复杂的点从来不在“能不能连上”，而在“连上之后怎么稳住、怎么扩、怎么不崩”。连接管理、心跳策略、消息序列化选型、断线重连语义（是否补推？推多少？），这些才是压测时最先露馅的地方。
