WebSocket本身没有粘包，因其基于RFC 6455定义的帧结构（含FIN位、opcode、payload length等），底层库自动完成帧的缓冲、重组与完整性校验，应用层ReadMessage()总返回完整消息。
WebSocket 协议本身已解决 TCP 层的粘包和拆包问题，Go 的 gorilla/websocket 或 golang.org/x/net/websocket 等主流库在读写时直接暴露「消息粒度」——conn.ReadMessage() 总是返回一个完整应用层消息，conn.WriteMessage() 也按整条消息发送。你不需要、也不应该在 WebSocket 上再做长度前缀或分隔符解析。
为什么 WebSocket 不会出现 TCP 粘包
因为 WebSocket 是基于 TCP 的应用层协议，但它定义了明确的帧（frame）结构：FIN、opcode、payload length 和掩码字段。浏览器和服务端实现都严格按 RFC 6455 解析帧边界。即使底层 TCP 把多个 WebSocket 帧拼成一个 TCP segment，或把一个大帧拆成多个 segment，gorilla/websocket 的 reader 也会内部缓冲、重组、校验，直到凑齐一帧才返回给你的应用代码。
常见误解：看到 conn.Read() 返回字节数少于预期，就以为“粘包了”——其实那是你在绕过框架直接操作底层 net.Conn，放弃了 WebSocket 帧解析能力。
- 不要调用
conn.(*websocket.Conn).UnderlyingConn().Read()读原始 TCP 数据 - 不要自己用
bufio.Reader包装 WebSocket 底层连接 - 不要对
ReadMessage()返回的[]byte再做长度前缀解包（除非你协议里额外套了一层）
gorilla/websocket 的 ReadMessage() 如何保证消息完整性
ReadMessage() 内部做了三件事：等待完整帧到达、验证 mask 和 length 字段、解包 payload。它不返回部分帧，也不会把两个独立的文本消息合并成一次返回。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误现象：
- 调用
ReadMessage()后得到空 slice 或 panic —— 很可能是客户端发了非法帧（如未 mask 的非服务端帧），gorilla直接关闭连接并返回*websocket.CloseError - 长时间阻塞在
ReadMessage()—— 说明没设读超时，必须配conn.SetReadDeadline() - 收到 JSON 但
json.Unmarshal报invalid character—— 实际是客户端发了非 UTF-8 文本帧（opcode=0x1），而gorilla默认只允许 UTF-8；可改用ReadBytes()或设websocket.Utf8CheckNone
什么时候需要自己处理“应用层粘包”
WebSocket 消息边界是清晰的，但业务逻辑可能把多个语义消息打包进一个 WebSocket 消息体里。比如：
- 客户端批量上报 10 条日志，拼成一个 JSON 数组发过来
- 服务端推送一个含多个事件的
struct{ Events []Event }结构 - 使用 Protocol Buffers 封装多条 record 到单个
bytes字段中
这时不是 TCP 粘包，而是你协议设计选择了「多路复用」。解法完全取决于序列化格式：
- JSON：直接
json.Unmarshal整个[]byte，别试图流式解析 - Protobuf：用
proto.Unmarshal，前提是 wire format 正确（如用LengthDelimited编码需先读长度） - 自定义二进制：若用了类似
4-byte-len + payload的嵌套协议，才需要像 TCP 场景那样用io.ReadFull先读头再读体
最容易被忽略的是：WebSocket 连接空闲时没人发消息，但 TCP keepalive 不等于应用层心跳。如果依赖 ReadMessage() 阻塞等待，又没设 SetReadDeadline，这个 goroutine 就永远卡住——不是粘包问题，是超时缺失。
