TCP粘包本质是其面向流无边界特性所致，必须在应用层定义协议边界：推荐固定长度头（如4字节大端序长度）方式，或使用不与业务冲突的分隔符；切忌依赖Read返回完整性或用Sleep等不可靠方式“猜测”包界。
TCP粘包问题本质是TCP面向流的特性导致的：数据没有天然边界，发送端多次Write可能被合并（粘包），或一次Write被拆成多次Read（拆包）。golang中不能依赖“一次Read对应一个业务包”，必须在应用层约定协议边界。核心思路只有两个：加长度头 或 加分隔符。
方案一：固定长度头部 + 消息体（推荐）
最常用、最高效、最易扩展的方式。在每条消息前加固定字节（如4字节）表示后续消息体长度。
- 发送端：先写4字节
uint32（大端序），再写原始数据；用binary.Write或binary.BigEndian.PutUint32确保字节序一致 - 接收端：先读够4字节 → 解出长度
n→ 再循环读满n字节 → 才算完整一条消息 - 关键细节：读取过程必须处理
io.EOF和io.ErrUnexpectedEOF；使用io.ReadFull代替conn.Read可自动重试未读满情况
方案二：自定义分隔符（适合文本协议）
在消息末尾添加特殊标记（如n、rn或0x00），适用于日志推送、简单指令等场景。
- 发送端：每次
Write后追加分隔符，例如conn.Write(append([]byte("hello"), 'n')) - 接收端：不能直接
Read，需用bufio.Scanner配合SplitFunc自定义切分逻辑，或手动缓存+查找分隔符位置 - 注意：分隔符必须保证不与业务数据冲突；若数据含二进制内容，不建议用此方案
避免常见错误实践
很多初学者试图靠time.Sleep、conn.SetReadDeadline或“等10ms再读”来“猜”包边界——这不可靠且严重损害性能和稳定性。
立即学习“go语言免费学习笔记（深入）”；
- 不要假设
Read会返回完整消息；TCP不保证消息粒度 - 不要在单个
Read调用后就解析；必须累积缓冲区，按协议规则切分 - 不要忽略
Read返回的n值；它可能小于预期，尤其在网络不稳定时
实用代码片段（长度头方式）
接收端核心逻辑示例：
// 缓冲区用于累积未处理数据 var buf bytes.Buffer for { // 先读4字节长度头 var header [4]byte if _, err := io.ReadFull(conn, header[:]); err != nil { log.Println("read header failed:", err) break } length := binary.BigEndian.Uint32(header[:]) // 再读length字节消息体 msg := make([]byte, length) if _, err := io.ReadFull(conn, msg); err != nil { log.Println("read message failed:", err) break } handle(msg) // 处理完整业务包 }更健壮的做法是把粘包处理封装为PacketConn或使用gob/protobuf序列化层自带长度前缀能力（如proto.MarshalOptions{Deterministic: true}配合自定义传输层）。
基本上就这些。选长度头还是分隔符，取决于你的协议是否允许嵌入控制字符、是否需要高性能、以及是否已有上下游约定。只要守住“边界由协议定义，不由TCP保证”这一条，粘包就不难解。