gorilla/websocket 是生产环境唯一可行的 WebSocket 实现，因其能承受真实连接压力；http.HandleFunc 会因自动关闭连接导致升级失败；CheckOrigin 必须精确校验 Origin 防伪造；并发读写需严格隔离 goroutine；心跳与超时需手动管理，配合读写 deadline 和连接池清理。
gorilla/websocket 是唯一能落地的起点，别指望标准库或其它小众包扛住真实连接压力。生产环境里它不是“推荐用”，而是“不用就出事”。
为什么 http.HandleFunc 会直接导致 WebSocket 升级失败
因为 http.HandleFunc 的 handler 执行完自动关闭连接，而 upgrader.Upgrade() 必须在连接未关闭前接管底层 net.Conn。一旦你写了 fmt.Fprint(w, "")、中间件调了 w.WriteHeader()，或者 handler 返回，就再也升不了级。
- 浏览器报错典型是
ERR_CONNECTION_CLOSED或websocket: bad handshake - 服务端日志常见
http: multiple response.WriteHeader calls - 路由必须走
http.ServeMux或直接传给http.Server，不能绕过它用http.HandleFunc注册后又另起 goroutine 处理 - 所有中间件（日志、鉴权、CORS）必须在
upgrader.Upgrade()前完成，且严禁向w写任何内容
upgrader.CheckOrigin 设为 return true 是上线即被扫的风险操作
开发时图省事开白名单放行，上线后等于把 WebSocket 端点暴露给任意域名——攻击者可伪造 Origin 发起连接，消耗你的连接数、内存、CPU，甚至触发 CSRF 式数据投毒。
- 必须从
r.Header.Get("Origin")提取完整协议+域名+端口，比如https://admin.example.com:8080 - 白名单用精确匹配，拒绝
strings.Contains或正则模糊校验（防evil.example.com伪装成example.com） - 若前端走 Nginx，需确保
X-Forwarded-Proto和X-Forwarded-Host被信任，并用它们拼 Origin 判断 - 不校验 Origin 时，
upgrader.CheckOrigin回调根本不会被调用——默认行为就是拒绝
并发读写 *websocket.Conn 必须严格隔离 goroutine
*websocket.Conn 不是线程安全的。两个 goroutine 同时调 conn.WriteMessage() 会 panic：concurrent write to connection；同理，ReadMessage() 并发调也会出问题。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 一个 goroutine 专责
ReadMessage()（处理客户端输入） - 另一个 goroutine 专责
WriteMessage()（推送看板数据、心跳、状态变更） - 用
chan或sync.Mutex控制写入队列，避免多个地方直接调WriteMessage - 别在
for {}循环里混着读和写——这是新手最常写的错误结构
心跳、超时、连接清理不能靠 conn.SetPingHandler 单独搞定
conn.SetPingHandler 只负责响应 Ping，不发送 Ping，也不处理超时断连。实际看板系统里，用户可能挂后台、网络中断、浏览器休眠，连接会卡住不主动关。
立即学习“go语言免费学习笔记（深入）”；
- 必须手动启动 goroutine 定期发
conn.WriteMessage(websocket.PingMessage, nil) - 用
conn.SetReadDeadline()配合每次ReadMessage()，超时就断开 - 用
conn.SetWriteDeadline()防止写阻塞拖垮整个连接池 - 所有连接要注册到全局 map（带
sync.Map或读写锁），断连时记得 clean up，否则 goroutine 泄漏 + 内存泄漏
