本文详解如何使用 Go 实现单连接下多文件的有序传输：服务端先读取文件数量，再循环接收每个文件名与大小，最后按指定字节数精确读取内容，避免 io.Copy 读取越界；同时提供基于 HTTP multipart 的更健壮替代方案。
本文详解如何使用 go 实现单连接下多文件的有序传输：服务端先读取文件数量，再循环接收每个文件名与大小，最后按指定字节数精确读取内容，避免 `io.copy` 读取越界；同时提供基于 http multipart 的更健壮替代方案。
在 Go 中通过原始 TCP 连接传输多个文件时，核心挑战在于流式协议缺乏天然的消息边界。你遇到的 io.Copy “吃掉后续文件数据”问题，本质是它会持续读取直到连接关闭（EOF），而你的协议设计却期望在同一连接上分段传输多个独立文件。解决的关键在于：显式声明每段数据的长度，并严格按长度截断读取。
✅ 正确的 TCP 多文件传输协议设计
推荐采用如下轻量级自定义协议（无需额外依赖）：
- 客户端首先发送文件总数（换行结尾）；
- 对每个文件：
- 发送文件名（换行结尾）；
- 发送文件字节长度（换行结尾）；
- 发送对应长度的原始文件字节流。
服务端严格遵循该顺序解析，使用 bufio.Reader 读取文本元信息，用 io.CopyN 精确读取二进制内容。
以下是修复后的完整服务端示例（含错误处理与资源安全）：
func getFileFromClient(conn net.Conn) {
defer conn.Close() // 确保连接最终关闭
r := bufio.NewReader(conn)
// 1. 读取文件总数
line, err := r.ReadString('\n')
if err != nil {
fmt.Printf("读取文件总数失败: %v\n", err)
return
}
countStr := strings.TrimSpace(line)
fileCount, err := strconv.Atoi(countStr)
if err != nil || fileCount <= 0 {
fmt.Printf("无效的文件数量: %s\n", countStr)
return
}
fmt.Printf("开始接收 %d 个文件...\n", fileCount)
// 2. 循环接收每个文件
for i := 0; i < fileCount; i++ {
// 读取文件名
fileName, err := r.ReadString('\n')
if err != nil {
fmt.Printf("第 %d 个文件: 读取文件名失败 %v\n", i+1, err)
return
}
fileName = strings.TrimSpace(fileName)
if fileName == "" {
fmt.Printf("第 %d 个文件: 文件名为空\n", i+1)
return
}
// 读取文件大小
sizeLine, err := r.ReadString('\n')
if err != nil {
fmt.Printf("第 %d 个文件 (%s): 读取大小失败 %v\n", i+1, fileName, err)
return
}
sizeStr := strings.TrimSpace(sizeLine)
fileSize, err := strconv.ParseInt(sizeStr, 10, 64)
if err != nil || fileSize < 0 {
fmt.Printf("第 %d 个文件 (%s): 无效文件大小 %s\n", i+1, fileName, sizeStr)
return
}
// 创建文件并写入指定字节数
f, err := os.Create(fileName)
if err != nil {
fmt.Printf("第 %d 个文件 (%s): 创建文件失败 %v\n", i+1, fileName, err)
return
}
// 注意：此处必须用 defer f.Close()，但需确保在 CopyN 后执行
// 更安全的做法是显式关闭（见下方注意事项）
n, err := io.CopyN(f, r, fileSize) // 直接从 bufio.Reader 读取，非原始 conn！
f.Close() // 显式关闭，避免 defer 延迟导致资源泄漏
if err != nil && err != io.EOF {
fmt.Printf("第 %d 个文件 (%s): 写入失败 %v (实际写入 %d 字节)\n", i+1, fileName, err, n)
return
}
fmt.Printf("✓ 第 %d 个文件 (%s): 已保存，大小 %d 字节\n", i+1, fileName, n)
}
}⚠️ 关键修正说明：
- io.CopyN(f, r, fileSize)：必须从 bufio.Reader r 而非原始 conn 读取。因为文件名、大小等元数据已由 r.ReadString() 消费，其内部缓冲区已包含后续文件数据。若直接读 conn，会跳过缓冲区，导致数据错位。
- defer f.Close() 在循环中不安全（可能覆盖前次句柄），应显式调用 f.Close()。
- 所有错误分支均提前返回，避免状态混乱。
? 更推荐的方案：使用 HTTP + Multipart
尽管 TCP 方案可行，但生产环境强烈建议迁移到标准 HTTP 协议——它天然支持多文件、流式上传、进度反馈、超时控制及成熟客户端生态（如 curl、Postman、前端 FormData）。
服务端仅需几行代码：
func uploadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
http.Error(w, "仅支持 POST", http.StatusMethodNotAllowed)
return
}
// 解析 multipart 表单
err := r.ParseMultipartForm(32 << 20) // 32MB 内存限制
if err != nil {
http.Error(w, "解析表单失败: "+err.Error(), http.StatusBadRequest)
return
}
// 遍历所有文件字段（假设字段名为 "files"）
for _, files := range r.MultipartForm.File {
for _, fileHeader := range files {
src, err := fileHeader.Open()
if err != nil {
http.Error(w, "打开文件失败", http.StatusInternalServerError)
return
}
defer src.Close()
dst, err := os.Create("./uploads/" + fileHeader.Filename)
if err != nil {
http.Error(w, "创建目标文件失败", http.StatusInternalServerError)
return
}
defer dst.Close()
if _, err := io.Copy(dst, src); err != nil {
http.Error(w, "保存文件失败", http.StatusInternalServerError)
return
}
fmt.Printf("已保存: %s\n", fileHeader.Filename)
}
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("上传完成"))
}
// 启动服务
http.HandleFunc("/upload", uploadHandler)
http.ListenAndServe(":8080", nil)客户端可使用 curl 快速测试：
curl -X POST http://localhost:8080/upload \ -F "files=@photo1.jpg" \ -F "files=@photo2.png" \ -F "files=@doc.pdf"
✅ 总结与最佳实践
- TCP 自定义协议适用场景：嵌入式、IoT 或对延迟/带宽有极致要求且无法引入 HTTP 栈的场景。务必严格遵循“长度前缀”模式，杜绝 io.Copy 在非 EOF 边界使用。
- HTTP Multipart 是默认首选：协议标准化、工具链完善、天然支持断点续传、权限控制、反向代理集成，且 Go 标准库 mime/multipart 实现健壮无坑。
- 安全提醒：生产环境需校验文件名（防止路径遍历 ../）、限制单文件大小、设置连接超时、添加鉴权中间件，并将上传目录与程序目录隔离。
选择哪种方式，取决于你的约束条件；但无论选哪条路，明确的数据边界 + 严谨的错误处理，永远是网络编程的基石。
