必须重写checkorigin，因默认拒绝所有跨域请求导致403；开发可返回true，生产须校验origin白名单，并透传upgrade/connection头，配writedeadline与单goroutine写，防阻塞和泄漏。
Go 的 gorilla/websocket 完全能撑住实时白板的并发交互，但默认配置下连接数一过百就掉帧、延迟飙升——问题不在协议，而在连接生命周期管理和消息广播方式。
为什么 websocket.Upgrader.CheckOrigin 必须重写
浏览器同源策略会拦截非同源 WebSocket 连接，Upgrader 默认拒绝所有跨域请求。开发时本地前端跑 http://localhost:3000、后端是 http://localhost:8080，不处理就直接 403。
- 必须显式覆盖
CheckOrigin函数，返回true（仅限开发环境）或校验r.Header.Get("Origin")白名单 - 切勿在生产环境无条件返回
true，否则任意站点都能发起连接，可能被用于 CSRF 或连接耗尽攻击 - 如果用 Nginx 反向代理，还要确保它透传
Upgrade和Connection头，否则Upgrade会失败，日志里只显示"websocket: not a websocket handshake"
conn.WriteMessage 阻塞？得配 WriteDeadline + 单独 goroutine
白板操作密集（如连续笔迹点），若一个客户端网络卡顿，WriteMessage 会阻塞整个广播 goroutine，其他用户立刻感知到延迟。这不是 bug，是 WebSocket 底层 TCP 写缓冲区满导致的正常阻塞。
- 每次写前必须调用
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，超时就断开该连接 - 广播逻辑不能在主线程里循环调用
WriteMessage，应为每个连接启动独立 goroutine：go func(c *websocket.Conn) { ... c.WriteMessage(...) } (conn) - 注意：goroutine 泄漏风险。需配合
context.WithCancel或在连接关闭时用sync.WaitGroup等待写 goroutine 退出
白板状态同步该用「全量快照」还是「增量操作」
语言学习场景下，学生常反复涂改、撤回、缩放画布——全量快照（每次广播整个 JSON 画布数据）带宽压力大；纯增量（只发“添加线条”“删除第3个图形”）则要求服务端维护每条操作的严格顺序和可逆性，出错难调试。
- 推荐混合模式：新连接建立时先发一次最小化快照（仅当前可见区域内的元素 ID + 基础属性），之后只广播操作指令（
"op":"stroke","id":"s123","points":[...]） - 关键约束：
op指令必须带单调递增的seq字段，客户端按序应用；服务端不校验逻辑冲突（如删掉不存在的图形），由前端做幂等处理 - 避免在服务端做操作合并（如把 10 次小移动合成一次大移动）——语言学习中“笔迹过程”本身就是教学信息，合并会丢失书写节奏
goroutine 泄漏比内存泄漏更隐蔽
一个未关闭的连接可能拖住 3–5 个 goroutine（读、写、心跳、超时监听、操作处理），连接数涨到 500 时，runtime.NumGoroutine() 轻松破 2000，而 pprof 的 /debug/pprof/goroutine?debug=2 页面里满屏都是 websocket.(*Conn).readLoop 和 io.ReadFull ——但这不是 bug，是连接没被主动 close。
- 务必在 HTTP handler 返回前调用
conn.Close()，并在 defer 中再次检查conn.IsClosed() - 心跳检测别只靠
Ping/Pong：客户端断网时Pong不会来，但 TCP 连接状态仍是 ESTABLISHED，需配合SetReadDeadline触发io.EOF才能真正清理 - 用
sync.Map存连接池时，删除 key 前先显式conn.Close()，否则 map 里残留已失效的指针，GC 清不掉
白板的实时性瓶颈从来不在 WebSocket 协议本身，而在于你有没有让每个连接“生得明确、活得可控、死得干净”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
