Buffalo 中 multipart/form-data 请求体默认不解析多文件，因其启动时仅调用一次 net/http 的 ParseMultipartForm 且 MaxMemory 默认为 32MB，未适配多文件场景，导致上传多个文件时触发 http.ErrMissingFile 或静默丢弃部分文件。
Buffalo 中 multipart/form-data 请求体默认不解析多文件
Buffalo 默认使用 net/http 的原生 ParseMultipartForm，但它在启动时只调用一次且未设置足够大的 MaxMemory，导致后续上传多个文件时触发 http.ErrMissingFile 或静默丢弃部分文件。这不是 Bug，而是 Buffalo 为兼顾表单文本字段而做的保守初始化。
- 默认
MaxMemory = 32 （32MB），但若未显式调用 <code>r.ParseMultipartForm()，r.MultipartForm为 nil，r.FormFile()会直接报错 -
c.Request().MultipartForm在中间件或 handler 中首次访问前，必须手动解析，否则FormFile和ParseMultipartForm都不可靠 - Buffalo 的
c.Param()、c.FormValue()对 multipart 数据无效——它们只读r.PostForm，而该字段在未解析 multipart 前为空
正确读取多个文件：先 ParseMultipartForm，再循环 FormFile
必须在 handler 开头显式调用 ParseMultipartForm，并传入合理内存阈值；否则所有 FormFile 调用都会失败或返回空。不要依赖 Buffalo 自动解析。
示例代码：
func UploadHandler(c buffalo.Context) error {
r := c.Request()
// 必须先解析，否则 r.MultipartForm == nil
if err := r.ParseMultipartForm(64 // 获取同名多文件字段（如 <input type="file" name="files" multiple>）
files, ok := r.MultipartForm.File["files"]
if !ok || len(files) == 0 {
return c.Error(400, fmt.Errorf("no files uploaded"))
}
for i, fileHeader := range files {
file, err := fileHeader.Open()
if err != nil {
return c.Error(500, err)
}
defer file.Close()
// 处理 file 句柄，例如保存到磁盘或上传到对象存储
_ = fmt.Sprintf("handling file %d: %s", i, fileHeader.Filename)
}
return c.Render(200, r.JSON(map[string]int{"uploaded": len(files)}))
}
64 是推荐起点（64MB），可根据业务调整；设太小会导致文件写入临时磁盘，影响性能；设太大可能耗尽内存- 字段名
"files"必须与 HTML 表单中<input name="files">完全一致，区分大小写 -
r.MultipartForm.File是map[string][]*multipart.FileHeader，同一字段名对应一个切片，不是单个值
常见错误：混用 c.FormValue 和 multipart 字段
如果表单同时含文本字段（如 title）和文件字段（如 files），不能用 c.FormValue("title") 读文本——它在 multipart 未解析前返回空。必须统一走 r.MultipartForm.Value。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 错误写法：
c.FormValue("title")→ 返回空字符串 - 正确写法：
title := r.MultipartForm.Value["title"][0]（注意判空） - 更安全写法：
if vals, ok := r.MultipartForm.Value["title"]; ok && len(vals) > 0 { title = vals[0] } - Buffalo 的
c.Param()完全不适用于表单数据，仅用于 URL 路径参数
生产环境需注意文件大小和超时控制
Buffalo 没有内置上传限流或分块支持，大文件上传容易触发连接超时或 OOM。关键控制点不在框架层，而在 http.Server 配置。
- 在
app.go初始化时，必须设置ReadTimeout和WriteTimeout，例如ReadTimeout: 30 * time.Second - 避免在 handler 中直接
io.Copy大文件到内存；应流式处理或用io.CopyN限制单次读取量 - 若前端用 Axios 或 Fetch，需显式设置
headers: {'Content-Type': 'multipart/form-data'}—— 实际上不该手动设，浏览器会自动生成带 boundary 的正确 header - 调试时可用
curl -F "files=@/path/to/a.txt" -F "files=@/path/to/b.txt" http://localhost:3000/upload验证后端逻辑
真正容易被忽略的是：Buffalo 不会帮你做文件名安全过滤、病毒扫描或去重校验，这些都得在 handler 里自己补全。别把上传入口当成信任边界。
