Go高级研发网络编程面试核心真题解析与考点-Golang-PHP中文网

go中处理tcp粘包拆包的正确方案是使用4字节大端序长度头协议：先读4字节得长度n，再用io.readfull读满n字节，循环解析缓冲区，每连接独享buffer，严格校验长度防oom。

go 网络编程面试中，真正卡人的不是 net.listen 怎么写，而是 tcp 粘包/拆包在真实服务中如何稳定落地——它直接暴露你对协议层、io 模型和错误边界的理解深度。

TCP 粘包的本质不是 Go 的 bug，而是字节流协议的必然行为

很多人一上来就翻 bufio.Scanner 或抄 DelimReader，但没意识到：TCP 本身不保证“消息边界”，它只管把字节块尽力送达。应用层看到的可能是：

两个 Write 调用被合并成一次 Read（粘包）
一个 Write 被拆成两次 Read（拆包）
Read 返回 n ，但不是 EOF，也不是错误——这是常态，不是异常

所以任何依赖“一次 Read 对应一个完整业务包”的逻辑，在高并发或弱网下必崩。

消息头+长度字段是生产环境唯一靠谱的方案

固定长度只适用于极少数场景（如硬件协议），而 bufio.Scanner 默认按行切分，根本没法处理二进制协议。工业级解法必须自己控制解析节奏：

头部用 binary.BigEndian.PutUint32 写入 4 字节 body 长度，body 紧跟其后
读取时先死磕 4 字节 header：用循环 io.ReadFull(conn, headerBuf)，不能只靠 conn.Read
拿到 bodyLen 后，再用 io.ReadFull(conn, bodyBuf) 读满 body，否则可能只读到一半
务必检查 bodyLen 是否过大（防内存爆炸），比如限制 ≤ 1MB

示例关键片段：

headerBuf := make([]byte, 4)
_, err := io.ReadFull(conn, headerBuf)
if err != nil { return }
bodyLen := binary.BigEndian.Uint32(headerBuf)
if bodyLen > 1024*1024 { // 安全阈值
    conn.Close()
    return
}
bodyBuf := make([]byte, bodyLen)
_, err = io.ReadFull(conn, bodyBuf) // 不是 conn.Read！
if err != nil { return }