应使用 gorilla/websocket 管理 WebSocket 连接，它封装了握手、帧处理、ping/pong 等生命周期操作；需双 goroutine 读写、带超时写通道、服务端补全时间戳与校验 clientId、用 sync.Map 管理连接、设置读超时与心跳，并优先优化广播范围与日志而非 JSON 性能。
WebSocket连接管理要用 gorilla/websocket 而不是标准库
Go 标准库没有原生 WebSocket 支持，net/http 只能做握手，后续帧处理必须自己写——没人这么干，容易出 unexpected EOF 或粘包。直接上 gorilla/websocket 是唯一合理选择。
它把连接生命周期封装得足够干净：Upgrader.Upgrade 做握手，*websocket.Conn 提供 WriteMessage/ReadMessage，自动处理 ping/pong、分帧、缓冲区复用。
- 别用
http.ResponseWriter手动写 101 状态——Upgrader内部已处理，手动写会触发http: multiple response.WriteHeader calls -
Upgrader.CheckOrigin默认拒绝所有跨域请求，开发时设为func(r *http.Request) bool { return true }，上线必须收紧 - 每个连接建议启动两个 goroutine：一个读（
ReadMessage），一个写（WriteMessage），用 channel 通信，避免阻塞
白板操作广播必须带客户端 ID 和时间戳
多人同步的核心不是“发出去”，而是“谁在什么时间改了什么”。没 ID 就没法做冲突检测，没时间戳就无法做因果排序或最终一致性合并。
前端传来的每条操作（比如 { "type": "draw", "points": [...], "clientId": "u_abc123", "ts": 1718234567890 }）后端不能原样广播——要补全服务端时间戳，并校验 clientId 是否合法（比如是否已登录、是否在当前房间）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 广播前务必用
json.Marshal序列化一次，别直接传原始 map——Go 的map非并发安全，多个 goroutine 同时读写会 panic - 别用
conn.WriteMessage循环推给每个 client：高并发下容易卡住某个慢连接拖垮整体，改用带超时的writeChan <- msg模式 - 如果白板支持撤回，服务端必须记录每个 client 的最后操作序列号（
seq），否则无法判断“撤回第 3 步”到底指哪一步
房间状态不能只靠内存 map，得考虑连接断开和重连
用 map[string]*Room 存房间、map[string]*websocket.Conn 存用户，看着简单，但掉线重连时极易出现状态不一致：旧连接没关干净，新连接又进来了，同一用户两个句柄同时收消息。
关键动作只有三个：进房时生成唯一 connectionId（不是 clientId），断开时触发 onClose 清理，重连时用 clientId + roomId 查是否有未完成的 session。
- 不要依赖
defer conn.Close()清理——网络闪断时 goroutine 可能卡在ReadMessage，根本走不到 defer - 给每个连接加
SetReadDeadline，配合心跳检测（比如每 30 秒发一次ping），超时就主动 close 并从房间 map 删除 - 房间内用户列表建议用
sync.Map，而不是普通 map +sync.RWMutex——前者对高读低写的场景更轻量，且避免锁粒度太粗
JSON 编解码性能差？先确认瓶颈真在这儿
白板操作消息体小（通常 json.Marshal/Unmarshal 在现代 CPU 上单次耗时约 10–50μs，远低于网络 RTT（通常 >50ms）。除非你每秒处理上万条操作，否则优化 JSON 不是优先级。
真正卡点往往在：1）没控制广播范围（向全站广播而非单房间）；2）日志打太细（比如每条操作都 log.Printf）；3）用了 fmt.Sprintf 拼接 JSON 字符串（会触发多次内存分配）。
- 别急着换
easyjson或ffjson——它们需要代码生成，增加构建复杂度，且 Go 1.20+ 的json包已优化很多 - 如果真要提速，优先做 message 复用：
sync.Pool缓存[]byte，避免每次广播都make([]byte, 0, 512) - 前端发来的操作，先用
json.RawMessage接收，只在需要字段校验时才解析——比如只检查type和clientId，其他字段延迟解析
同步逻辑越往后走，越容易在“谁该删谁该留”这种边界上翻车。比如一个用户断网 2 分钟后重连，他本地画了 17 笔，服务端却只记得最后 5 笔——这时候不是 JSON 快不快的问题，是状态快照和操作日志怎么存、存多久的问题。
