Go语言需用gorilla/websocket库处理WebSocket，因net/http仅支持升级握手，不解析RFC 6455二进制帧；须用Upgrader.Upgrade获取*websocket.Conn，设Deadline、正确关闭，并自行管理会话与消息协议。
Go 语言本身不内置 WebSocket 支持，必须依赖 gorilla/websocket 这类成熟第三方库才能稳定处理连接升级、心跳、消息收发等关键逻辑——标准库 net/http 只能帮你完成 HTTP 升级握手，后续帧解析、掩码校验、控制帧处理全得自己写，不推荐。
为什么不能只用 net/http 处理 WebSocket 升级
HTTP 协议的 Upgrade 请求头只是“协商阶段”，真正建立 WebSocket 连接后，通信格式就切换为二进制帧（RFC 6455），包含 opcode、mask、payload length 等字段。net/http 完全不解析这些，你拿到的 http.ResponseWriter 和 *http.Request 在升级成功后就失效了。常见错误是：调用 conn.Write() 前没做掩码（客户端强制要求），或忽略 Ping/Pong 帧导致连接被浏览器静默关闭。
实操建议：
- 必须用
gorilla/websocket的Upgrader.Upgrade()获取*websocket.Conn实例，它已封装所有帧编解码逻辑 -
checkorigin默认拒绝跨域，开发时设为func(r *http.Request) bool { return true }，但上线前必须改成白名单校验r.Header.Get("Origin") - 别在
http.HandlerFunc里直接读写ResponseWriter，升级后所有 IO 都走*websocket.Conn
gorilla/websocket 连接生命周期管理要点
语言学习类应用（如实时翻译、单词协作板、口语陪练）通常需要维持长连接并区分用户上下文，但 gorilla/websocket 不提供会话管理，需自行绑定连接与业务状态。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 在
Upgrade()成功后，立即将*websocket.Conn存入 map 或 sync.Map，key 可用conn.RemoteAddr().String()或 JWT 解析出的 user_id - 务必设置
conn.SetReadDeadline()和conn.SetWriteDeadline()，否则网络异常时 goroutine 会永久阻塞 -
conn.Close()要放在defer里，且需捕获websocket.IsUnexpectedCloseError()判断是否为正常断开 - 避免在 handler 中直接
conn.WriteMessage()广播——高并发下易 panic，改用 channel + 单独 writer goroutine
语言学习场景下的消息协议设计陷阱
前端发送的可能是语音片段、打字内容、选择题答案，后端需区分类型路由到不同业务逻辑。若直接用原始字符串或 JSON，容易因字段缺失、类型错乱导致 panic。
实操建议：
- 定义最小协议结构：
{"type":"translate","data":{"text":"hello","from":"en","to":"zh"}}，type字段必须校验，未知 type 直接conn.WriteMessage(websocket.TextMessage, []byte(`{"error":"unknown type"}`)) - 对
data字段用json.Unmarshal()时，先声明 struct 并加json:"text,omitempty"标签，避免空字段覆盖默认值 - 语音数据不要走 WebSocket 文本帧，改用
websocket.BinaryMessage+ base64 编码，否则 UTF-8 校验失败 - 心跳用
Ping帧（由库自动处理），别自己发{"type":"ping"}—— 浏览器可能丢弃非标准 ping
最常被忽略的是连接复用：语言学习 App 用户可能频繁切页面（比如从单词页跳到听力页），但 WebSocket 连接不应每次重建。需要前端在 onbeforeunload 里主动 close()，后端监听 websocket.CloseMessage 类型并清理资源，否则连接数会指数级堆积。
