tcp是字节流协议，不保证消息边界；客户端一次write的多个逻辑单元（如命令+文件内容）可能被服务端一次read全部读取，导致命令解析错误。解决方法是设计明确的消息分隔协议，而非依赖底层传输行为。
tcp是字节流协议，不保证消息边界；客户端一次write的多个逻辑单元（如命令+文件内容）可能被服务端一次read全部读取，导致命令解析错误。解决方法是设计明确的消息分隔协议，而非依赖底层传输行为。
在Go中使用net.Conn进行TCP通信时，一个常见误区是假设Write()和Read()之间存在天然的一一对应关系。但事实是：TCP本身不提供消息边界（message boundary）——它只保证字节流的有序、可靠传输。网络栈可将多次小写入合并为一个TCP段发送，也可将单次大写入拆分为多个段；接收端的Read()则可能一次性返回多个逻辑“消息”的字节，也可能将一个消息拆成多次返回。这正是你遇到问题的根本原因："send xyz.txt"和后续文件内容被粘包（TCP packet coalescing），导致服务端Read()一次性读到"send xyz.txtHello world"。
✅ 正确做法：定义应用层协议
你需要在应用层显式界定消息边界。以下是两种推荐方案：
方案1：长度前缀（推荐）
在每条消息前添加4字节（或固定长度）的长度字段，服务端先读取长度，再按需读取对应字节数。
客户端发送逻辑（修正版）：
func sendFileToServer(fileName string, conn net.Conn) error {
w := bufio.NewWriter(conn)
defer conn.Close()
// 1. 发送命令消息："send <filename>"
cmd := "send " + fileName + "\n" // 显式换行作为命令结束符（或用长度前缀）
if _, err := w.Write([]byte(cmd)); err != nil {
return err
}
// 2. 发送文件内容（无需额外分隔，由协议约定：命令后即为文件体）
file, err := os.Open(fileName)
if err != nil {
return err
}
defer file.Close()
_, err = io.Copy(w, file) // 高效流式传输
if err != nil {
return err
}
return w.Flush()
}</filename>
服务端解析逻辑（修正版）：
func connectionHandler(conn net.Conn, bufferChan chan []byte, stringChan chan string) {
defer conn.Close()
r := bufio.NewReader(conn)
// 步骤1：读取命令行（以\n为界）
cmdLine, err := r.ReadString('\n')
if err != nil {
fmt.Println("Failed to read command:", err)
stringChan 0 {
data := make([]byte, n)
copy(data, buf[:n])
bufferChan <h4>方案2：定界符（简单场景可用）</h4><p>用特殊字符（如<code>\n</code>、<code>\0</code>）分隔逻辑消息。注意：文件内容中若含该字符需转义或避免使用。</p><blockquote>
<p>⚠️ 注意事项：</p>
<ul>
<li>
<strong>永远不要依赖<code>bufio.Reader.Read()</code>的返回字节数匹配某次<code>Write()</code></strong>；</li>
<li>
<code>bufio.Writer.Flush()</code>仅确保数据提交到内核缓冲区，不控制网络分包；</li>
<li>客户端原代码中<code>go func(){...}()</code>协程+channel的同步方式冗余且易出错，应直接顺序执行；</li>
<li>服务端原代码使用<code>connection.Read(buffer)</code>未处理实际读取长度（<code>n</code>），且未清理缓冲区残留字节（如<code>\x00</code>填充），极易引发解析错误；</li>
<li>文件读取推荐用<code>io.Copy()</code>替代手动循环，更简洁安全。</li>
</ul>
</blockquote><h3>总结</h3><p>TCP的流特性不是Bug，而是设计本质。可靠的网络程序必须在应用层定义并实现消息边界——无论是长度前缀、分隔符，还是更复杂的协议（如HTTP、gRPC）。忽略这一点，仅靠“运气”调试，终将在高负载或不同网络环境下重现粘包问题。从现在开始，把“消息边界”作为协议设计的第一原则。</p>
