基于Golang与Gin框架构建精简版的在线文件大块直传-Golang-PHP中文网

c.formfile 不能用于大文件直传，因其底层调用 parsemultipartform 将整个请求体（含所有字段和文件）一次性加载到内存，导致 oom；正确做法是使用 ctx.request.multipartreader() 流式处理。

基于golang与gin框架构建精简版的在线文件大块直传

c.FormFile 不能用于大文件直传，它会把整个文件读进内存，几百 MB 就可能触发 runtime: out of memory；真·直传必须绕过 Gin 默认的 multipart 解析，用 ctx.Request.MultipartReader() 流式消费每个 part。

为什么不能直接用 `c.FormFile` 做大块直传

它底层调用 ParseMultipartForm，强制将整个请求体（含所有字段 + 文件）一次性加载到内存。哪怕只传一个 500MB 文件，Gin 就会尝试分配等量内存 —— 并发稍高，OOM 是必然结果。更糟的是，你连“上传中校验权限”或“边读边转码”都做不到，因为文件内容早已全在内存里了。

错误现象：panic: runtime: out of memory 或 Nginx 返回 502 Bad Gateway（因上游连接被强制关闭）
即使设了 r.MaxMultipartMemory = 100 ，也只是限制大小，不改变“全量加载”行为
c.SaveUploadedFile 同样依赖 c.FormFile，本质没区别

如何用 `MultipartReader` 实现真正流式直传

关键不是“怎么读”，而是“别让 Gin 提前读”。必须禁用自动解析，否则 c.Request.Body 已为空，MultipartReader() 会直接返回 io.ErrUnexpectedEOF。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

不要调用 r.MaxMultipartMemory（或留默认值但不触发解析）
handler 内第一行就调用 c.Request.MultipartReader()，不要碰 c.FormFile、c.PostForm 等任何会触发 ParseMultipartForm 的方法
用 part.FormName() 区分字段和文件：普通字段用 part.Read() 拿值；文件字段则用 io.Copy(dst, part) 直接流式写入磁盘或对象存储

示例片段：

reader, err := c.Request.MultipartReader()
if err != nil {
    c.AbortWithStatusJSON(400, gin.H{"error": "invalid multipart"})
    return
}
for {
    part, err := reader.NextPart()
    if err == io.EOF {
        break
    }
    if err != nil {
        c.AbortWithStatusJSON(400, gin.H{"error": err.Error()})
        return
    }
    if part.FormName() == "file" {
        f, _ := os.Create("/tmp/upload-" + uuid.New().String())
        defer f.Close()
        io.Copy(f, part) // 这里才是真正的“直传”
    }
}

中文文件名、断点续传与安全边界怎么处理

直传不等于裸传。生产环境必须补上三件事：文件名安全解码、分片状态持久化、路径白名单校验。

客户端传的 filename 必须用 url.PathEscape 编码（不是 QueryEscape），服务端收到后用 url.PathUnescape 解码，再做 filepath.Clean + 白名单比对，防 ../etc/passwd 路径遍历
断点续传不是靠 Gin 自带能力，得自己存分片元数据：比如用 Redis 记录 file_id → [chunk_0, chunk_2, chunk_5]，上传前先查缺失索引
流式写入时别用 os.Create 直接写用户指定路径 —— 临时文件应固定在 /tmp 或独立挂载卷，合并后再移到最终目录
如果文件需校验（如 MD5），必须在 io.Copy 过程中同步计算哈希，而不是等写完再 os.Open 重读 —— 那又回到内存瓶颈