本文详解如何使用 Go 的标准库（无需第三方包）实现单连接下多文件的有序传输，核心在于为每个文件显式传递长度信息，并配合 io.CopyN 精确读取，避免 io.Copy 误读后续数据。
本文详解如何使用 go 的标准库（无需第三方包）实现单连接下多文件的有序传输，核心在于为每个文件显式传递长度信息，并配合 `io.copyn` 精确读取，避免 `io.copy` 误读后续数据。
在 Go 中通过 TCP 单连接传输多个文件，关键在于协议设计与流控制。原始代码失败的根本原因在于：io.Copy(conn, dst) 会持续读取直到连接关闭（EOF），导致第一个文件就耗尽整个连接缓冲区，后续文件名和内容无法被正确解析。解决方案不是放弃单连接，而是引入定长元数据协商机制——即在每个文件数据前，先发送其字节长度。
以下是完整、健壮的服务端接收逻辑（含错误处理与资源清理）：
func getFileFromClient(conn net.Conn) {
defer conn.Close() // 确保连接最终关闭
r := bufio.NewReader(conn)
// 1. 读取文件总数
line, err := r.ReadString('\n')
if err != nil {
log.Printf("读取文件总数失败: %v", err)
return
}
n, err := strconv.Atoi(strings.TrimSpace(line))
if err != nil || n <= 0 {
log.Printf("无效文件数量: %s", line)
return
}
log.Printf("开始接收 %d 个文件", n)
// 2. 循环接收每个文件
for i := 0; i < n; i++ {
// 2.1 读取文件名（以换行符结尾）
fileName, err := r.ReadString('\n')
if err != nil {
log.Printf("第 %d 个文件：读取文件名失败 %v", i+1, err)
return
}
fileName = strings.TrimSpace(fileName)
if fileName == "" {
log.Printf("第 %d 个文件：空文件名", i+1)
return
}
// 2.2 读取文件大小（以换行符结尾）
sizeLine, err := r.ReadString('\n')
if err != nil {
log.Printf("第 %d 个文件（%s）：读取大小失败 %v", i+1, fileName, err)
return
}
size, err := strconv.ParseInt(strings.TrimSpace(sizeLine), 10, 64)
if err != nil || size < 0 {
log.Printf("第 %d 个文件（%s）：无效文件大小 %s", i+1, fileName, sizeLine)
return
}
// 2.3 创建文件并精确写入指定字节数
f, err := os.Create(fileName)
if err != nil {
log.Printf("第 %d 个文件（%s）：创建文件失败 %v", i+1, fileName, err)
return
}
// 注意：此处必须用 defer f.Close() *在循环内*，否则仅关闭最后一个文件
defer f.Close()
// 使用 CopyN 精确复制 size 字节，避免越界读取
written, err := io.CopyN(f, r, size)
if err != nil && err != io.EOF {
log.Printf("第 %d 个文件（%s）：写入失败 %v", i+1, fileName, err)
return
}
if written != size {
log.Printf("第 %d 个文件（%s）：写入字节数不匹配，期望 %d，实际 %d",
i+1, fileName, size, written)
return
}
log.Printf("✅ 第 %d 个文件（%s）接收完成，大小 %d 字节", i+1, fileName, size)
}
}⚠️ 客户端配合要点（不可省略）：
- 每次发送文件前，按顺序发送：\n\n
- 文件大小必须是十进制 ASCII 字符串（如 "1024"），末尾带 \n
- 使用 bufio.Writer 提升小数据包效率，并在每次 WriteString/Write 后调用 Flush()
? 为什么 bufio.Reader 不是问题？
bufio.Reader 本身无害，问题在于 io.Copy 的语义——它不关心应用层协议边界。bufio.Reader 反而有助于减少系统调用次数，只要上层协议明确分隔（如换行符 + 显式长度），它就是最佳搭档。
✅ 更优替代方案（生产推荐）：
若需更高可靠性、进度反馈或与 Web 生态集成，强烈建议改用 HTTP + multipart/form-data：
- 服务端：r.MultipartReader() + part.Next() 遍历文件
- 客户端：multipart.Writer 构建请求体
- 优势：内置边界解析、编码支持（如中文文件名）、可复用 HTTP 工具链（curl、Postman）、天然支持 TLS 和代理
总结：单连接多文件传输完全可行，核心是显式长度协商 + io.CopyN 精确消费。避免 io.Copy 的“读到 EOF”陷阱，用协议定义数据边界，即可在 Go 标准库中构建高效、可控的文件传输通道。
