WebSocket二进制通信需显式启用并规范处理：服务端须调用SetReadLimit/Deadline，读取前确认BinaryMessage类型，禁用json.Unmarshal解析二进制帧，应定义固定格式并用binary.Read解析；gorilla/websocket.WriteMessage非零拷贝，大帧宜用WriteBinary+io.Copy。
WebSocket 连接必须显式启用二进制模式
Go 标准库 net/http 自带的 http.ServeHTTP 不会自动识别二进制帧；默认所有 websocket.MessageRead 都走文本路径。若不主动切换，conn.ReadMessage() 会尝试 UTF-8 解码，遇到非文本字节直接返回 websocket.ErrCloseSent 或 json.Unmarshal 类错误。
实操建议：
- 服务端创建连接后立即调用
conn.SetReadLimit(1024 * 1024)和conn.SetReadDeadline(...)，避免二进制粘包或超长 payload 导致阻塞 - 使用
conn.ReadMessage()前，确保客户端已发送websocket.BinaryMessage类型帧（浏览器需用ws.binaryType = 'arraybuffer'） - 读取时优先用
conn.ReadMessage()获取messageType, data, err，再根据messageType == websocket.BinaryMessage分支处理
二进制协议解析不能依赖 json.Unmarshal 直接解包
JSON 是文本协议，对 []byte 中的控制字符、\x00、未对齐 padding 等极其敏感。一旦二进制结构含长度前缀、CRC 校验或自定义 tag，直接喂给 json.Unmarshal 必然 panic 或静默失败。
实操建议：
- 定义明确的二进制帧格式，例如：
[uint32 len][uint8 cmd][uint16 seq][payload]，用binary.Read(bytes.NewReader(data), binary.BigEndian, &header)拆解 - 避免在协议层混用文本与二进制字段；如需元信息，统一用 protobuf 或
gob编码，而非拼接 JSON 字符串 - 若必须兼容旧 JSON 接口，单独开一个
/api/json路由，不要和/ws共享同一套解包逻辑
gorilla/websocket 的 WriteMessage 对二进制数据零拷贝不成立
很多人误以为传入 []byte 就是零拷贝——实际 gorilla/websocket.WriteMessage(websocket.BinaryMessage, data) 内部仍会调用 conn.writeBuf.Write() 复制一份到 write buffer。当单帧 >64KB 且高频发送时，GC 压力明显上升。
实操建议：
- 大块数据（如图像帧、音频 chunk）改用
conn.WriteBinary()+io.Copy()组合，绕过中间writeBuf缓冲区 - 小消息（WriteMessage，但务必复用
[]byte底层切片，避免每次 new - 设置
conn.SetWriteBuffer(1024 * 1024)提升吞吐，但注意该值不能超过 OS socket send buffer 限制（Linux 可查/proc/sys/net/core/wmem_max）
心跳与二进制帧的混合处理容易丢帧
标准 WebSocket ping/pong 帧由底层自动响应，但 Go 的 gorilla/websocket 默认把 ping 当作控制帧丢弃，不触发 ReadMessage。如果业务逻辑依赖“收到任意帧即刷新心跳计时器”，而恰好只监听 BinaryMessage，就会漏判客户端存活状态。
实操建议：
- 启用
conn.SetPongHandler()，并在 handler 内调用conn.SetReadDeadline(time.Now().Add(30 * time.Second))显式刷新超时 - 不要在
ReadMessage循环里写if messageType == websocket.TextMessage { ... }就跳过，所有帧类型（包括PingMessage、PongMessage）都应被读取并处理 - 若协议要求心跳携带序列号或时间戳，必须用自定义二进制心跳帧（cmd=0x01），而非依赖底层 ping
二进制协议真正的复杂点不在编码本身，而在帧边界判定、跨平台字节序一致性、以及连接中断时未完成帧的恢复逻辑——这些没法靠库自动解决，得在协议设计初期就约定清楚。
