TCP 是字节流协议，不存在天然的“消息边界”；Go 的 net.Conn.Read() 会阻塞直到有数据可读或连接关闭，无法“非阻塞地读取完整消息”，正确做法是基于协议定义（如长度前缀或分隔符）逐步解析流数据。
tcp 是字节流协议，不存在天然的“消息边界”；go 的 `net.conn.read()` 会阻塞直到有数据可读或连接关闭，无法“非阻塞地读取完整消息”，正确做法是基于协议定义（如长度前缀或分隔符）逐步解析流数据。
在 Go 中实现 TCP 服务器时，一个常见误区是期望 net.Conn.Read() 能“一次性读取一条完整应用层消息”。但必须明确：TCP 本身不提供消息语义——它只保证字节流的有序、可靠传输。客户端调用一次 send() 发送的数据，可能被拆分成多个 TCP 段到达；而服务端一次 Read() 可能只读到部分数据，也可能合并多个逻辑消息（尤其当发送间隔极短时）。因此，所谓“读取一整条命令而不阻塞”，在 TCP 层面本质上是不可行且无意义的。
你的协议格式 COMMAND
- 逐字节/逐行读取首部：使用 bufio.Reader 读取首行（以 \r\n 结尾），解析出 BODY_LENGTH；
- 按需读取定长主体：调用 io.ReadFull() 或循环 Read() 确保读满 bodyLength 字节；
- 容错处理非法输入：若首行解析失败（如缺失 \r\n、数字格式错误），跳过直至下一个 \r\n（即丢弃当前不完整行），继续尝试解析下一行。
以下是推荐的健壮实现示例：
func handler(c net.Conn) {
defer c.Close()
reader := bufio.NewReader(c)
writer := bufio.NewWriter(c)
defer writer.Flush()
for {
// 步骤1：读取命令头行（含 \r\n）
line, err := reader.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)
// 丢弃当前不完整行，继续下一轮
continue
}
// 去除 \r\n，解析 COMMAND 和 BODY_LENGTH
line = strings.TrimSuffix(line, "\r\n")
fields := strings.Fields(line)
if len(fields) <p><strong>关键注意事项：</strong></p>
- ✅ 永远不要依赖单次 Read() 获取完整消息：net.Conn.Read() 的行为由底层 TCP 缓冲区和网络状况决定，必须配合协议解析逻辑；
- ✅ 使用 bufio.Reader 提升效率：避免小包频繁系统调用，ReadString() 和 ReadFull() 封装了阻塞等待逻辑，符合 Go 的并发模型；
- ✅ 错误处理要面向协议而非连接：单条命令格式错误不应直接断连，而应跳过并同步到下一个合法起始点（如 \r\n 后），提升鲁棒性；
- ❌ 切勿尝试“非阻塞读取所有缓冲数据”：SetReadDeadline() 或 SetNonblock() 在常规 TCP 服务器中易引发竞态和复杂状态管理，违背 Go “通过通信共享内存”的设计哲学；
- ⚠️ 注意粘包与拆包：本协议依赖 \r\n 边界，若 BODY 内容意外含 \r\n，则协议设计本身存在缺陷，需额外转义或改用纯长度前缀（如 4 字节大端整数）。
总结：TCP 协议层没有“消息”，只有字节流；所谓“读取消息”本质是应用层协议解析过程。正确的 Go 实现应聚焦于协议定义（长度/分隔符）、使用 bufio 工具链、编写可恢复的解析逻辑，而非追求底层非阻塞读取——这既不可靠，也不必要。
