答案：Go语言解决TCP粘包问题必须在应用层定义消息边界，因TCP是字节流协议，conn.Read()不保证返回完整消息，可能粘包、半包或仅部分长度头；推荐用4字节大端长度头+io.ReadFull两次读取，并严格处理EOF与ErrUnexpectedEOF。
Go 语言中解决 TCP 粘包问题，核心不是“修复 TCP”，而是**必须在应用层定义消息边界**；不加协议约定，conn.Read() 返回的数据永远不可直接解析。
为什么 conn.Read() 不能直接用
TCP 是字节流，不保留 Write() 调用边界。一次 conn.Read(buf) 可能返回：
- 多个消息拼在一起（粘包），比如
"len=5\0hellolen=3\0bye" - 只读到某个消息的前半截（半包），比如
"len=5\0hel"，剩下"lo"下次才到 - 甚至空读（
n == 0）或仅返回长度头的前 2 字节
依赖 Read() 的返回长度、加 time.Sleep() 或设 SetReadDeadline() 猜包尾，全是线上事故温床。
用 io.ReadFull 读长度头 + payload
最通用、生产环境首选方案：每条消息以 4 字节大端整数开头，表示后续 payload 长度。
发送端必须用 binary.BigEndian.PutUint32() 写头，接收端用 io.ReadFull() 两次读取：
- 先读满 4 字节到
headerBuf := make([]byte, 4) - 调
binary.BigEndian.Uint32(headerBuf)解出msgLen - 再分配
payloadBuf := make([]byte, msgLen)，用io.ReadFull(conn, payloadBuf)读满
关键点：io.ReadFull 会自动重试未读满情况，比手动循环 Read() 更简洁可靠；但必须检查返回的 err —— io.EOF 表示连接关闭，io.ErrUnexpectedEOF 表示对端提前断连或协议错乱。
用 bufio.Scanner 处理分隔符协议
适合纯文本、且业务数据**绝对不含**该分隔符的场景，比如日志行、简单指令。常用 '\n' 或 0x00。
不能用 strings.Split(string(buf), "\n") 手动切分 —— 因为 buf 可能没读完，末尾无 \n，导致丢掉最后一条不完整消息。
正确做法是：
- 用
bufio.NewScanner(conn) - 调
scanner.Split(bufio.ScanLines)或自定义SplitFunc - 若消息可能超长（如大 JSON），必须提前调
scanner.Buffer(nil, 10*1024*1024)扩容，否则报scanner: token too long
注意：如果原始数据含 \n（比如设备上报的 base64 日志），此方案直接失效，必须换长度头。
别踩这些坑
常见错误操作包括：
- 把
conn.Read(buf)返回的n当作一条完整消息长度 —— 它只是本次内核缓冲区可用字节数 - 用
binary.Write(conn, binary.LittleEndian, ...)写长度头 —— 两端字节序不一致会导致msgLen解错，直接 panic 或死锁 - 忽略
io.ReadFull的 error 判断，把ErrUnexpectedEOF当普通错误吞掉，导致后续所有消息解析偏移 - 在高并发服务中为每个连接起 goroutine 做阻塞读，却不设读超时或最大帧长限制 —— 半包卡住后连接永久 hang 住
真正难的不是写对那几行 io.ReadFull，而是让整个连接生命周期里，每次读都严格按协议推进状态机，并在任何异常路径下都能释放资源、记录可定位日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
