Go multipart 上传文件为空通常是哪一步出错

Go multipart 上传文件为空，先看 FormFile 是否返回错误，再比较客户端 File.size、服务端 FileHeader.Size 和 io.Copy 的字节数。字段名或 boundary 不一致通常表现为解析失败或找不到文件；解析大小大于零但复制为零，优先查文件读取游标；已经复制非零却看到空文件，则继续查写入错误、实际路径和后续覆盖。

我建议先保留这些可比较的值，别一开始就把所有问题归成“Go 没收到文件”。下文给出一个本机诊断配方：字段统一为 file，使用一种解析路径，临时写入后返回计数。示例是原创代码，未在本机运行，也不展示虚构请求结果。

Go multipart 官方文档：https://pkg.go.dev/mime/multipart

HTTP 请求接口：https://pkg.go.dev/net/http

先分清现象：字段缺失和零字节不是同一件事

请求整体大小还包含 boundary、字段头和普通表单字段，不能把 ContentLength 直接当作文件字节数。客户端也可能用分块等方式发送，不能单靠该字段判断有无文件。

最小配方：浏览器提交同一个文件字段

在已有同源页面放置一个 id="pick" 的文件输入框和 id="send" 的按钮，再使用下面的事件代码。重点是提交 File 对象，不是输入框的 value 字符串；FormData 的字段名必须和服务端一致。

document.querySelector("#send").addEventListener("click", async () => {
    const chosen = document.querySelector("#pick").files[0];
    if (!chosen) {
        throw new Error("请先选择一个文件");
    }
    // file 必须对应 Go 服务端的 FormFile("file")。
    const form = new FormData();
    form.append("file", chosen, chosen.name);
    console.log("selectedBytes", chosen.size);

    // 让浏览器生成包含正确 boundary 的 Content-Type。
    const response = await fetch("/upload", { method: "POST", body: form });
    const message = await response.text();
    if (!response.ok) {
        throw new Error(message);
    }
    console.log(message);
});

不要手动把 Content-Type 固定为不带 boundary 的 multipart/form-data。boundary 是请求头和实际正文共同遵守的分隔符，不能任意拼一个不同值。若是 Go 客户端使用 multipart.Writer，则采用它的 FormDataContentType()，并在完成文件写入后处理 Writer.Close 的错误，让结尾分隔符写完整。

这里不需要 CSS。先确认文件对象和表单协议，再讨论页面样式，才不会把文件路径文字误当成文件内容。

关键参数：解析方式和读取游标

小型表单诊断可以用 ParseMultipartForm 加 FormFile；流式处理则用 MultipartReader 遍历 part。它们是两种读取请求体的路径，不应在同一请求上先完整解析再尝试从原 Body 重新开始流式读。请求 Body 是流，通常不会自动回到起点。

ParseMultipartForm(maxMemory) 中的 maxMemory 是文件部分的内存存储阈值，超出的部分可进入临时文件，不是上传体积上限。要限制整个请求体，在解析前使用 MaxBytesReader，同时给 multipart 的额外开销留出余量。

另一个常见原因发生在解析以后：为了算摘要或打印内容，代码先把 multipart.File 读完，随后直接 io.Copy 保存。复制从当前游标继续，到 EOF 时自然得到零字节。若持有的是 FormFile 返回的可定位文件，可以在处理 Seek 错误后回到起点，或通过 FileHeader.Open 重新打开并负责关闭；流式 Part 不能直接套用文件 Seek 的做法。

// f 是 FormFile 成功返回的文件；检查游标复位错误再保存。
if _, err := f.Seek(0, io.SeekStart); err != nil {
    return fmt.Errorf("复位上传文件: %w", err)
}
// dst 是调用方已经创建、负责关闭的目标文件。
n, err := io.Copy(dst, f)
if err != nil {
    return fmt.Errorf("复制上传内容，已写 %d 字节: %w", n, err)
}

这个片段需要放入有 error 返回值的函数，并导入 fmt 和 io。若中间件在解析之前已经读尽原始 Body，应先调整中间件的请求体处理；对后来打开的文件 Seek 无法修复一个已被提前耗尽的请求。

完整片段：同时观察解析大小和复制字节数

下面是本机诊断程序：只监听回环地址，最多接收八 MiB 请求体，解析文件时的内存阈值为一 MiB。文件写入随机命名的临时文件，完成后删除，不以客户端文件名作为落盘路径。这段程序用于观察复制结果，不是持久保存上传附件的业务接口。

package main

import (
    "errors"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
)

func upload(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
        http.Error(w, "只接受 POST", http.StatusMethodNotAllowed)
        return
    }
    // 先限制整个请求，再解析；阈值并非单文件业务配额。
    r.Body = http.MaxBytesReader(w, r.Body, 8

同源前端片段需要由相同来源的已有页面使用，本程序只提供上传端点，不提供 HTML 页面。也可以用命令行单独向该端点发送文件。示例中零字节被主动拒绝，这属于业务判断；multipart 格式本身允许某些文件部分没有内容，不能把它们都归类为解析器故障。

变体与坑点：从数字差异决定查哪里

当 parsedBytes 与客户端 selectedBytes 都为零，先回到文件选择或 Blob 构造逻辑；当客户端非零但解析报错，检查字段、boundary、客户端 Writer 收尾和代理或服务端限制；当解析成功且非零，但复制很少或为零，检查是否做过前置读取，以及复制返回的错误。

io.Copy 在返回错误前可能已经写入部分内容，不能只看 n 大于零就报告成功。目标文件 Close 的错误也不应被成功响应遮住。如果写入包了 bufio.Writer，还必须处理 Flush，否则用户态缓冲区可能没有完整写到底层文件。示例直接写 os.File，没有额外的缓冲层。

若采用 multipart.Reader 流式变体，应区分 part.FormName、part.FileName 和 part 内容：普通表单字段不是文件；读取当前 part 的内容必须在推进到后续 part 之前完成。流式处理不要假设有 FileHeader.Size 可直接比较，应自行计数，并保留对整个请求体的限制。

为什么 FormValue("file") 是空字符串？它用于普通字段，读取文件用 FormFile；而且 FormValue 会忽略解析返回的错误，不适合作为文件解析成功的依据。

为什么把内存阈值调大仍然失败？内存阈值控制存储分配方式，不消除请求体上限、代理限制或传输格式错误，先看实际返回错误属于哪一类。

FileHeader.Size 非零就一定保存成功吗？不能。它描述解析出的文件大小，保存还涉及源游标、目标写入、关闭以及是否读取了正确目标。

为什么多个文件只得到一个？FormFile 返回该字段的第一个文件。多文件使用解析结果中的文件头列表或相应流式策略，不要把取到首个条目和后续文件缺失混为一谈。

FormData 使用说明：https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API/Using_FormData_Objects