Golang Web文件上传如何限制大小_上传安全控制方法_技术教程

必须显式设置 r.ParseMultipartForm(maxMemory)，否则无限制导致内存或磁盘耗尽；maxMemory 控制内存缓存上限，超限自动落盘；纯流式处理应跳过该调用，改用 r.MultipartReader()；完整请求体还需用 http.MaxBytesReader 作字节级防护。

Go HTTP 上传时 `r.ParseMultipartForm` 的大小限制必须显式设置

默认情况下，http.Request.ParseMultipartForm 不设限，会把整个 multipart body 全部读入内存（甚至临时磁盘），极易被恶意大文件打满内存或填满磁盘。不调用它或不设参数，不等于“没限制”——而是等于“无防护”。

必须在调用前用 r.ParseMultipartForm(maxMemory) 显式指定内存缓冲上限（单位字节），否则后续

r.FormFile 或 r.MultipartReader 可能直接 panic 或阻塞。

maxMemory 是内存中缓存的上限，超过部分自动落盘到 os.TempDir()；设为 0 仍会使用默认值（32MB），不可省略
若只想纯流式处理、完全避免内存/磁盘缓存，应跳过 ParseMultipartForm，直接用 r.MultipartReader()
注意：该限制只作用于 form-data 的 value 部分（即文件内容 + 文本字段），不控制整个请求体长度——完整请求头+body 还需额外用中间件限制

用 `http.MaxBytesReader` 拦截超长请求体（含 header + body）

http.MaxBytesReader 是 Go 标准库提供的底层防护，它包装 http.ResponseWriter 的 ResponseWriter.Body，对整个请求流做字节级截断。这是防止攻击者发送 1GB 垃圾数据绕过 ParseMultipartForm 限制的最后防线。

它必须放在路由处理函数最开头，且包装的是 r.Body，不是响应体：

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    const maxRequestSize = 10 << 20 // 10MB
    r.Body = http.MaxBytesReader(w, r.Body, maxRequestSize)
    // 后续再 ParseMultipartForm 或读取
}

一旦超出，r.Body.Read() 会返回 http.ErrBodyReadAfterClose 或 io.EOF，通常伴随 HTTP 400 响应
它不解析 multipart 结构，因此必须在 ParseMultipartForm 之前生效，否则 multipart 解析器可能已开始读取并触发 OOM
不能只靠它替代 ParseMultipartForm 的限制——两者职责不同：一个控总长，一个控表单解析行为

校验 `Content-Length` 头是否可信 & 防止 chunked bypass

攻击者可省略 Content-Length，改用 Transfer-Encoding: chunked 发送流式数据，绕过基于长度的静态检查。Go 的 http.MaxBytesReader 对 chunked 编码依然有效，但你不能依赖 r.ContentLength 做前置判断。

r.ContentLength 在 chunked 请求中为 -1，不可信；不要用它做 if 判断
某些代理或负载均衡器可能篡改或删除 Content-Length，需以 MaxBytesReader 为准
若需记录原始大小，应在 MaxBytesReader 包装后，用自定义 io.Reader 统计实际读取字节数（并在读完后检查是否达上限）

文件保存前必须重命名 + 检查 MIME 类型 + 禁用执行权限

用户传来的 filename 字段完全不可信，直接拼路径会导致目录遍历（如 ../../etc/passwd）；仅靠后缀过滤无法防 MIME type spoofing（如把恶意二进制命名为 pic.jpg）。

用 filepath.Base() 提取原始文件名，再用 uuid.New().String() 生成存储名，彻底丢弃客户端 filename
用 file.Header.Open() 打开后，读取前 512 字节传给 http.DetectContentType，比对白名单（如 image/jpeg, application/pdf）
保存时显式设置文件权限：用 ioutil.WriteFile(path, data, 0644) 或 os.OpenFile(..., 0644)，确保无执行位（0755 是危险的）
不要用 os.Chmod 补救——写入瞬间若被竞态利用，可能短暂存在可执行文件