Go TCP 消息怎么按长度拆包：处理粘包与半包

用 Go 写 TCP 服务时，最容易误判的一件事是：发送端调用了一次 Write，接收端就应该对应一次 Read。TCP 只负责连续、有序地传输字节，不替应用保留消息边界，所以一条消息可能被拆成几次读出来，也可能和下一条消息一起到达。

处理粘包与半包的核心不是反复调整 Read 的缓冲区，而是给协议增加明确的帧边界。本文采用“4 字节大端长度 + payload”，接收端先用 io.ReadFull 读满长度，再按长度读满正文，并在分配内存前检查最大帧大小。

先把 TCP 字节流和消息边界分开

net.Conn 的语义是面向流的网络连接。假设客户端连续发送“订单”和“心跳”两帧，服务端可能先读到订单的一部分，也可能一次读到订单剩余内容和心跳开头。前者是半包，后者通常被称为粘包；它们不是 TCP 出错，而是应用层没有定义 framing。

因此不要用“本次 Read 返回了多少字节”判断一条消息结束，也不要把固定大小的临时缓冲区当成协议。可靠的判断依据应该来自消息自身：固定长度、分隔符，或者本例的长度前缀。

约定长度前缀和最大帧大小

协议可以规定每帧前 4 个字节存放 payload 长度，使用 binary.BigEndian 编解码。长度字段只描述正文，不包含自身；例如正文是 11 字节，帧就是 4 字节 header 加 11 字节 payload。关键是把上限写进协议实现，避免对异常长度直接 make([]byte, length)。

长度字段的字节序不是“性能参数”，而是协议兼容性的一部分。如果一端用小端写、另一端用大端读，长度会被解释成完全不同的值。跨语言通信时应把它写进协议文档，并为 0 长度帧是否允许给出明确结论。

按固定阶段读取完整帧

接收端可以把读取拆成两个不可混淆的阶段：先读取 4 字节 header，再读取 header 声明的 payload。io.ReadFull 的价值在于它会持续读取，直到填满目标切片或返回错误；连接提前结束时，能区分完全没有读到数据的 io.EOF 和读到一部分后的 io.ErrUnexpectedEOF。

package frame

import (
    "encoding/binary"
    "fmt"
    "io"
)

const MaxFrameSize = 1  MaxFrameSize {
        return nil, fmt.Errorf("frame too large: %d", size) // 先校验，再申请正文缓冲区
    }

    payload := make([]byte, size)
    if _, err := io.ReadFull(r, payload); err != nil {
        return nil, err // 正文未读满时，不能把半包交给业务层
    }
    return payload, nil
}

这里的 size 是 uint32，比较上限时应让上限使用可比较的无符号类型，或显式转换后再比较。若协议不允许空消息，可以在长度检查处拒绝 0；若允许，io.ReadFull 对零长度切片会立即完成，业务层仍需决定它代表心跳还是空事件。

发送端、错误处理和回归检查要一起设计

发送端也必须先构造完整帧，再确保帧写入连接。对于一般小消息，可以用一个缓冲区承载 header 和 payload；更大的消息则要注意 Write 可能只写入部分字节，不能忽略返回的 n。

func WriteFrame(w io.Writer, payload []byte) error {
    if uint64(len(payload)) > uint64(MaxFrameSize) {
        return fmt.Errorf("frame too large: %d", len(payload)) // 发送端同样执行上限检查
    }

    frame := make([]byte, 4+len(payload))
    binary.BigEndian.PutUint32(frame[:4], uint32(len(payload))) // 与接收端使用同一字节序
    copy(frame[4:], payload) // header 后紧跟正文，不混入额外分隔符

    for len(frame) > 0 {
        n, err := w.Write(frame)
        if err != nil {
            return err // 网络错误发生时停止，避免继续写入不完整协议帧
        }
        if n == 0 {
            return io.ErrShortWrite // Writer 未推进游标，继续循环会造成死循环
        }
        frame = frame[n:]
    }
    return nil
}

回归时至少覆盖四种输入：完整单帧、一个连接中连续两帧、只到达部分 header、header 完整但 payload 不完整；再补一个超过上限的长度字段。测试可以使用 bytes.Buffer 或自定义分段 Reader 模拟网络分段，无需假定操作系统每次如何返回。

常见问题

把 Read 缓冲区调大能解决粘包吗？

不能。缓冲区只影响一次调用最多接收多少字节，不能创建消息边界；仍应按协议帧解析，并循环消费同一连接中的剩余字节。

为什么不用 binary.Read 直接读取结构体？

固定 header 可以用 binary.Read，但长度前缀协议仍需单独检查上限并完整读取 payload。显式的 ReadFull 更容易把半包和资源边界写清楚。

长度字段应该用大端还是小端？

两者都可以，重点是协议双方一致并写入文档。面向跨语言或公开协议时，通常会选定一种稳定字节序，而不是让实现自行猜测。