Go 文件上传如何限制 multipart 请求体：MaxBytesReader 与 ParseMultipartForm 的安全边界

文件上传接口最容易被忽略的不是保存路径，而是请求还没走到业务校验前，服务端已经接收了多少字节。Go 里只调用 ParseMultipartForm 并不能替代入口限流：生产代码应先用 http.MaxBytesReader 限制整个 HTTP 请求体，再解析 multipart，最后对每个文件做大小、名称和内容类型校验。

把限制拆成“整个请求体、表单解析内存、单文件和最终落盘”四层，超限时统一返回 413，并记录实际大小与请求 ID，上传接口才有可控的内存和磁盘边界。

先在 net/http 入口卡住整个请求体

假设头像接口最多接收 8 MiB，入口处理顺序应该是：创建带限制的读取器、调用 ParseMultipartForm、检查文件字段。顺序反过来，解析器已经有机会处理大量数据，后面的限制就只是补救。

const maxUploadBody = 8 

MaxBytesReader 触发后，解析阶段通常会收到超限错误。这里返回 413 是给调用方的稳定契约；日志里仍应保留原始错误，避免把损坏的 multipart 边界误判成普通业务缺字段。

ParseMultipartForm 的 2 MiB 不是单文件限制

ParseMultipartForm(maxMemory) 的参数容易被误读。它描述的是解析 multipart 时允许放在内存中的部分，超过这部分的数据可能落到临时文件；它不会替你规定每个文件只能有多大，也不会自动拒绝一个合法但很大的上传。

例如整个请求上限是 8 MiB，内存阈值设为 2 MiB，单文件上限设为 5 MiB。两个 4 MiB 文件虽然没有突破总请求上限，却应该因为单文件规则或文件数量规则被拒绝。限制要互相覆盖，而不是只写一个数字。

文件级校验要看大小、名称和真实内容

拿到 FileHeader 后先检查元数据，再读取文件开头判断内容类型。上传者传来的 Content-Type 和文件扩展名都只能作为提示，不能单独决定是否保存。

const maxAvatarSize = 5  maxAvatarSize {
        return fmt.Errorf("avatar exceeds %d bytes", maxAvatarSize)
    }

    name := filepath.Base(header.Filename)
    if name == "." || name == ".." || name == "" {
        return errors.New("invalid file name")
    }

    head := make([]byte, 512)
    n, err := io.ReadFull(file, head)
    if err != nil && !errors.Is(err, io.ErrUnexpectedEOF) {
        return err
    }
    kind := http.DetectContentType(head[:n])
    if kind != "image/jpeg" && kind != "image/png" {
        return fmt.Errorf("unsupported content type: %s", kind)
    }
    return nil
}

读取文件头会改变文件游标，后续保存前要重新定位，或者把已读取的字节与剩余内容一起写入目标文件。这个小细节在本地测试里不明显，上线后会表现为图片开头损坏。

临时文件、路径和失败清理必须有边界

multipart 解析可能使用临时文件，保存失败时不要只返回错误就结束。应用应把目标文件名改成服务端生成的 ID，使用固定上传文件夹，并在校验失败或写入中断时清理临时资源。原始文件名可以写进审计日志，但不要直接拼进存储路径。

func safeTarget(dir, id, ext string) string {
    return filepath.Join(dir, id+ext)
}

// 保存完成后再把临时文件切换为可访问状态；失败时删除未完成目标。
func cleanup(path string, err error) error {
    if err != nil {
        _ = os.Remove(path)
    }
    return err
}

如果服务部署在容器里，还要给临时文件夹和上传文件夹设置可观察的磁盘配额。请求体限制挡住的是网络输入，挡不住已有临时文件堆积、重复上传和恶意文件名带来的运维问题。

用四组请求把安全配置验收一遍

不要只上传一张正常图片就结束验收。至少准备四组样本：小于限制的合法文件、刚好接近边界的文件、突破整个请求体的请求、扩展名正确但内容类型错误的文件。

1. 合法小文件应返回 200 或业务约定的成功码，落盘文件可被重新读取。
2. 单文件超过 5 MiB 时返回 413，服务端不留下半截目标文件。
3. 请求体超过 8 MiB 时在表单解析阶段被拒绝，日志含 request_id、路径和错误类型。
4. 伪装成 PNG 的文本文件返回 415 或 400，不能仅因为后缀正确就进入公开路径。

压测时同时观察进程 RSS、临时文件夹大小和 413 数量。若 RSS 随并发线性上升，先看 ParseMultipartForm 的内存阈值和文件读取方式；若磁盘增长，检查临时文件清理与客户端重试。

常见问题：Go multipart 上传限制怎么选

只设置 Content-Length 检查够不够？

不够。客户端可以省略或伪造它，服务端仍需用 MaxBytesReader 限制实际读取的字节数。

ParseMultipartForm 会自动删除临时文件吗？

它可能创建临时文件，生命周期和清理应由应用流程与运行环境共同确认。不要把“解析成功”当成磁盘已回收。

为什么 FileHeader.Size 不能代替读取计数？

它来自 multipart 元数据，适合做快速拒绝；最终仍要以服务端实际读取和写入的字节数为准，尤其是自定义存储或转码流程。

超限时一定要返回 413 吗？

对请求体或文件确实超过策略上限的情况，413 最容易让客户端区分“请缩小文件”和“字段缺失”。字段格式错误则可使用 400 或 415，并保持接口文档一致。

把上传限制写进接口契约和发布检查

最终配置可以记成一张小表：请求体 8 MiB、单文件 5 MiB、内存解析 2 MiB、只允许 JPEG/PNG、失败清理目标文件。接口文档、监控告警和回归样本都引用同一组数字，后续修改时就不会只改了代码却忘记网关或客户端。