Go处理TCP粘包的核心是识别消息边界，推荐使用4字节大端序长度头协议：先读头部获消息长度，再按长读body，需循环解析缓冲区、每连接独享buffer，并全程嵌入I/O生命周期管理。
Go 处理 TCP 粘包问题，核心不是“避免”，而是“识别消息边界”——因为 TCP 本身不提供消息概念，net.Conn.Read 返回的只是字节流，应用层必须自己定义并解析包结构。
用长度头协议（Length-Prefixed）是最稳妥的通用方案
在每条消息前加固定长度的头部（如 4 字节 uint32），标明后续 body 的真实长度。接收方先读够头部，再按该长度读 body，天然支持粘包、半包、多包合并等所有边界情况。
- 推荐用
binary.BigEndian（网络字节序），兼容性比LittleEndian更广，尤其跨语言通信时 - 头部长度建议统一为 4 字节（
uint32），覆盖最大 4GB 消息（实际业务中极少超几 MB） - 不要在封包时直接
append头部和 body 后就Write——要确保写入是原子的，否则可能只写出头部就中断，导致接收方卡死 - 解包逻辑必须循环处理缓冲区：一次
Read可能含多个完整包 + 半包，不能假设“读一次就一个包”
func pack(msg []byte) []byte {
header := make([]byte, 4)
binary.BigEndian.PutUint32(header, uint32(len(msg)))
return append(header, msg...)
}
func unpack(buf *bytes.Buffer) ([]byte, error) {
if buf.Len() < 4 {
return nil, io.ErrUnexpectedEOF // 数据不够头
}
header := make([]byte, 4)
buf.Read(header) // 安全：buf 是可读写的
msgLen := binary.BigEndian.Uint32(header)
if int(msgLen) > buf.Len() {
buf.UnreadByte() // 把 header 放回去，等下次数据
return nil, io.ErrUnexpectedEOF
}
data := make([]byte, msgLen)
buf.Read(data)
return data, nil
}
别用分隔符（如 \n 或自定义字符串）除非你完全控制数据内容
看似简单，但极易翻车：只要业务数据里出现分隔符（比如日志里带换行、JSON 字段含 "\n"、用户输入含 "[END]"），就会错切消息。
- 如果坚持用分隔符，必须做转义（如把
\n编码为\\n），等于自己实现简易协议，复杂度不比长度头低 -
bufio.Scanner默认按\n切分，但它内部也是边读边找分隔符，一旦数据含未转义换行，就会提前截断 - 测试时用纯英文短句看不出问题，上线后用户发个带表情或代码块的消息，立刻暴露
bufio.Reader.ReadBytes 不解决粘包，反而掩盖问题
它只是帮你“找到第一个分隔符就停”，但没解决“分隔符在中间被截断”或“多个消息挤在一次 Read 里”的根本问题。
- 若底层连接一次返回
"hello\nworld\n"，ReadBytes('\n')会返回"hello\n"和"world\n"两次，看似正常；但若返回"hel"+"lo\nworld\n"，第一次调用会阻塞等待，第二次才拿到完整"lo\n"—— 这就是典型的半包，你得自己缓存"hel" - 它无法处理无分隔符的二进制数据（如 protobuf、加密 payload）
- 真正可靠的解包必须维护状态（当前已读多少、还差多少、是否在包内），而
ReadBytes是无状态的
别忽略连接粒度的缓冲区管理
每个 net.Conn 都应配独立缓冲区（如 *bytes.Buffer 或 ring buffer），而不是全局共用一个。否则多个 goroutine 并发读同一连接时会竞争、错乱。
- 常见错误：启动一个
goroutine调用io.Copy把 conn 全量读到全局 buffer，再由另一个 goroutine 去拆包——这违反了 TCP 流的顺序性和单连接独占性 - 正确做法：每个连接的 handler 内部持有一个
*bytes.Buffer，每次Read后WriteTo进去，再循环调用unpack直到 buffer 剩余不足一个包 - 注意
bytes.Buffer不是并发安全的，若需多 goroutine 协作（如异步解密+解包），改用sync.Pool管理 buffer 实例
最常被忽略的一点：粘包处理不是“一次封装就能一劳永逸”的事，它必须嵌入整个 I/O 生命周期——从 Read 的错误判断、缓冲区增长策略、到包解析失败时的丢弃/重同步逻辑。少一步，上线后就可能收不到心跳、解析不出登录请求、或者某天突然开始批量丢指令。
