TCP 是面向字节流的协议，不存在天然的“消息边界”；Go 的 net.Conn.Read 会阻塞直到有数据可读或连接关闭，无法无长度信息地“读取一整条消息”，必须通过协议设计（如长度前缀、分隔符）来界定消息边界。
tcp 是面向字节流的协议，不存在天然的“消息边界”；go 的 `net.conn.read` 会阻塞直到有数据可读或连接关闭，无法无长度信息地“读取一整条消息”，必须通过协议设计（如长度前缀、分隔符）来界定消息边界。
在 Go 中实现 TCP 服务端时，一个常见误区是将 TCP 当作“消息管道”——期待每次 Read() 调用能恰好读取客户端一次 Write() 发送的完整逻辑消息（例如一条 COMMAND 12\r\n{...}\r\n）。但事实是：TCP 不提供消息语义。它只保证字节流的有序、可靠传输，不保证：
- 一次 send() / Write() 的数据会以单次 recv() / Read() 返回；
- 多次小写入可能被合并（Nagle 算法、内核缓冲等）；
- 一次大写入可能被拆分为多次 Read() 返回；
- 接收缓冲区大小（如 []byte{1024}）决定了单次最多读多少，而非“一条消息”。
因此，你代码中 c.Read(msg) 并不能保证读到完整的命令行（含 \r\n），更无法保证后续 Read() 恰好读到指定长度的 BODY —— 如果网络延迟、丢包重传或缓冲区未满，第二次 Read() 就会阻塞，且无法“跳过错误数据并同步到下一条合法消息”。
✅ 正确做法：基于协议定义明确的消息边界，主动解析，而非依赖系统“自动分包”。
你的协议格式 COMMAND <BODY_LENGTH>\r\n<BODY>\r\n 实际已隐含了两种边界机制：
- 行尾 \r\n 标记命令头结束；
- <BODY_LENGTH> 显式声明主体字节数。
推荐使用 bufio.Reader 分层解析，兼顾健壮性与性能：
func handler(c net.Conn) {
defer c.Close()
br := bufio.NewReader(c)
for {
// 1. 读取命令行（以 \r\n 结尾）
line, err := br.ReadString('\n')
if err != nil {
if errors.Is(err, io.EOF) || errors.Is(err, io.ErrUnexpectedEOF) {
log.Println("Client closed connection")
return
}
log.Printf("Read header error: %v", err)
// 错误处理：丢弃当前不完整行，尝试同步到下一个 \r\n
discardToNextLine(br)
continue
}
// 清除 \r\n，解析 COMMAND 和 BODY_LENGTH
line = strings.TrimSuffix(strings.TrimSuffix(line, "\n"), "\r")
if !strings.HasPrefix(line, "COMMAND ") {
log.Printf("Invalid command line: %s", line)
discardToNextLine(br) // 同步到下一行
continue
}
parts := strings.Fields(line)
if len(parts) < 2 {
log.Printf("Missing body length in: %s", line)
discardToNextLine(br)
continue
}
bodyLen, err := strconv.Atoi(parts[1])
if err != nil || bodyLen < 0 {
log.Printf("Invalid body length: %s", parts[1])
discardToNextLine(br)
continue
}
// 2. 读取指定长度的 BODY（注意：可能跨多个 Read）
body := make([]byte, bodyLen)
_, err = io.ReadFull(br, body) // 阻塞直到读满 bodyLen 字节
if err != nil {
log.Printf("Failed to read body: %v", err)
// 若读不满，说明连接异常或协议错乱，建议关闭连接
return
}
// 3. 读取并丢弃结尾 \r\n（可选，取决于协议严格性）
tail, _ := br.Peek(2)
if len(tail) >= 2 && string(tail) == "\r\n" {
br.Discard(2)
}
// 4. 处理并响应
response := handleCommand(parts[0], body)
if _, err := c.Write(response); err != nil {
log.Printf("Write response failed: %v", err)
return
}
}
}
// 辅助函数：跳过当前不完整数据，寻找下一个 \r\n 同步点
func discardToNextLine(r *bufio.Reader) {
for {
b, err := r.ReadByte()
if err != nil {
return
}
if b == '\n' {
return
}
if b == '\r' {
// 检查是否为 \r\n
if nb, _ := r.Peek(1); len(nb) > 0 && nb[0] == '\n' {
r.Discard(1)
}
return
}
}
}⚠️ 关键注意事项：
- 永远不要假设 Read() 返回完整消息：必须循环读取或使用 io.ReadFull / bufio.Scanner / bufio.Reader 等工具按需消费；
- 错误恢复需谨慎：对格式错误的输入，discardToNextLine 是一种实用的“协议同步”策略，但无法 100% 抵御恶意或严重损坏的数据流；生产环境建议增加最大丢弃字节数限制（如 Discard(4096) 后强制断连）；
- 不要关闭连接来“重置状态”：TCP 连接开销低，复用连接是高效设计；频繁重连反而暴露协议脆弱性；
- net.Conn.Read 确实会阻塞，直到有数据到达或连接关闭（io.EOF）——这是 TCP 协议栈的正常行为，并非 Go 的缺陷。
总结：解决该问题的核心不是“如何非阻塞读取消息”，而是接受 TCP 的流式本质，用确定性解析逻辑（而非系统调用语义）重建消息边界。你的协议已有良好基础（长度前缀 + 分隔符），只需用 bufio.Reader 和 io.ReadFull 正确实现，即可稳定、高效、容错地处理任意网络条件下的命令流。
