ctx.formfile不能直接用于大文件上传，因为它会将整个文件载入内存再返回*multipart.fileheader，易触发oom；应改用ctx.request.multipartreader()流式分块处理，避免内存堆积。
上传大文件时内存爆满，ctx.FormFile 为什么不能直接用？
因为 ctx.FormFile 会把整个文件读进内存再返回 *multipart.FileHeader，对几百 MB 的文件极易触发 OOM。真正流式上传必须绕过它，直接操作底层 ctx.Request.Body。
实际做法是：禁用 Gin 默认的 Multipart 解析（避免提前读取），手动解析 boundary 并分块读取。但更稳妥的方式是——不自己解析，改用 ctx.Request.MultipartReader()，它返回一个标准 multipart.Reader，天然支持按 part 流式消费：
// 关键：禁用自动解析，否则 Request.Body 已被读空
r := gin.New()
r.Use(gin.Recovery())
// 不调用 r.MaxMultipartMemory(...) 或留默认 32MB，仅作限制，不启用自动解析
func uploadHandler(c *gin.Context) {
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
}
// 检查是否为文件字段（比如 "file"）
if part.FormName() == "file" {
// 此时 part 是 io.Reader，可直接 io.Copy 到磁盘或远端存储
dst, _ := os.Create("/tmp/" + filepath.Base(part.FileName()))
io.Copy(dst, part) // 真正的流式，无内存堆积
dst.Close()
}
}
c.JSON(200, gin.H{"ok": true})
}
注意：c.Request.MultipartReader() 要求请求头 Content-Type 必须含 boundary=...，且不能在调用前访问 c.PostForm* 或 c.FormFile，否则 Request.Body 已被消耗。
下载时如何避免 os.ReadFile 把整个文件加载进内存？
用 http.ServeContent 或直接 io.Copy 配合 os.Open 返回的 *os.File（实现了 io.ReadSeeker），就能实现零拷贝响应。
关键点不是“能不能流”，而是“是否支持断点续传和 Range 请求”——这取决于你是否提供文件大小和修改时间：
- 如果只用
c.DataFromReader，不设Content-Length，客户端无法预估进度，也不支持暂停续传 - 如果用
c.Header("Content-Length", sizeStr)+io.Copy(c.Writer, file)，能流式发，但没Last-Modified和ETag，HTTP 缓存和 Range 处理要自己补 - 最省心的是
http.ServeContent，它自动处理Range、If-Range、304 Not Modified，但要求传入io.ReadSeeker和已知长度/时间
推荐写法：
func downloadHandler(c *gin.Context) {
filePath := "/path/to/large.zip"
file, err := os.Open(filePath)
if err != nil {
c.AbortWithStatus(404)
return
}
defer file.Close()
fileInfo, _ := file.Stat()
c.Header("Content-Disposition", `attachment; filename="`+fileInfo.Name()+`"`)
// ServeContent 自动处理 Range、缓存、304
http.ServeContent(c.Writer, c.Request, fileInfo.Name(), fileInfo.ModTime(), file)
}
注意：file 必须支持 Seek()，*os.File 满足；但 bytes.Reader 或网络流不行。
Gin 中设置超时和流控，为什么 ReadTimeout 对上传无效？
因为 ReadTimeout 只作用于请求头读取阶段，而文件体传输属于 “body read” 阶段，不受其约束。上传卡住时，服务可能一直挂着连接却不报错。
真正有效的控制方式有三层：
- HTTP 层：用
gin.SetMode(gin.ReleaseMode)避免调试日志拖慢；设置http.Server.ReadHeaderTimeout（防恶意不发 header） - 连接层：在
http.Server上设ReadTimeout和WriteTimeout—— 但注意：它们从连接建立开始计时，非单次读写 - 业务层：对
multipart.Reader或文件读取加 context 超时，例如ctx, cancel := context.WithTimeout(c.Request.Context(), 10*time.Minute)，然后用io.CopyN或带 cancel 的 reader 包装
简单起见，推荐在 handler 内部控制：
ctx, cancel := context.WithTimeout(c.Request.Context(), 15*time.Minute)
defer cancel()
reader, _ := c.Request.MultipartReader()
for {
part, err := reader.NextPart()
if err != nil {
if errors.Is(err, io.EOF) { break }
c.AbortWithStatusJSON(400, gin.H{"error": "read part failed"})
return
}
// 用带超时的 writer，或检查 ctx.Err() 每次循环
if ctx.Err() != nil {
c.AbortWithStatus(408)
return
}
...
}
前端用 fetch 上传大文件时，为什么看不到实时进度？
因为默认 fetch 不暴露上传过程，必须用 ReadableStream + ProgressEvent 手动构造可监听的 body。
核心不是 Gin 做什么，而是前端能否把文件切片、分块上传并合并——但如果你坚持单请求流式上传，就得用 XMLHttpRequest（它原生支持 upload.onprogress），或用 fetch 配合 TransformStream 包装文件流并注入进度逻辑（Chrome 109+ 支持）：
const file = document.querySelector('input[type=file]').files[0];
const stream = file.stream();
const { readable, writable } = new TransformStream({
transform(chunk, controller) {
// 这里可以更新进度条
updateProgress((controller.desiredSize || 0) / file.size);
controller.enqueue(chunk);
}
});
await fetch('/upload', {
method: 'POST',
body: readable,
headers: { 'Content-Type': 'multipart/form-data; boundary=...' } // 注意：fetch 不自动设 boundary，需后端兼容无 boundary 的 raw body
});
更现实的做法是：后端接受 raw body（即 c.Request.Body 整体当文件流），前端用 fetch 直接传 file.arrayBuffer() 或 file.stream()，后端跳过 multipart 解析，直接保存——这样最可控，也无需处理 boundary。
边界情况容易被忽略：Nginx 默认限制 1MB 上传体，且会缓冲整个 body 再转发给 Go；若中间有代理或 CDN，它们可能根本不支持流式透传，此时必须确认整条链路都允许长连接与大包传输。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
