如何巧妙应对Golang中TCP粘包与拆包的复杂挑战？

本文共计832个文字，预计阅读时间需要4分钟。

`Go 的 net.Conn.Read 从不保证一次只读取一个应用层消息——它仅按内核缓冲区的当前状态返回多寡。因此，粘包和拆包不是 bug，而是 TCP 的自然行为。必须在应用层定义并解析消息边界，否则 json.Unmarshal 报 invalid character、结构体字段全零、binary.Read 卡在 EOF 等都是过早的问题。`

为什么不能依赖 bufio.Scanner 或 ReadString

这些工具只适合纯文本、有明确分隔符（比如 \n）的协议。一旦数据里含未转义的换行、JSON 字段带 \n、用户输入含表情或代码块，Scanner.Scan() 就会提前截断；ReadString('\n') 则可能永远阻塞——因为二进制 payload 根本不含 \n。

• 它们内部靠不断扩容 buffer 扫描，性能差，且无法表达空消息（长度为 0）
• 不解决“头被截半”或“多个包拼一起”的根本问题，只是把问题藏得更深
• 调试时看似正常，压测或长连接跑几小时后开始丢包、panic

用 binary.Write + io.ReadFull 实现长度前缀协议

最可控、跨语言兼容性最好的方式：每个消息以 4 字节大端序 uint32 开头，表示后续 payload 长度。