Buffalo框架需手动解析multipart/form-data，推荐先调用ParseMultipartForm(32
Buffalo 框架里怎么接多图上传表单
Buffalo 默认不带文件上传中间件，multipart/form-data 请求体需要手动解析。直接用 c.Request().MultipartReader() 容易出错——比如没调用 ParseMultipartForm 就读取，会触发 http: multipart: NextPart: EOF 错误。
推荐用标准库 mime/multipart 配合 maxMemory 限制内存占用：
err := c.Request().ParseMultipartForm(32 << 20) // 32MB 内存上限
if err != nil {
return c.Error(400, err)
}
files, ok := c.Request().MultipartForm.File["images"]
if !ok || len(files) == 0 {
return c.Error(400, fmt.Errorf("no images uploaded"))
}
- 务必在读取前调用
ParseMultipartForm，否则File字段为空 32 是硬性内存阈值，超限部分会写入临时磁盘，避免 OOM- 字段名
"images"要和 HTML 表单的name="images"严格一致，且需加multiple属性
上传后怎么批量调用图像压缩库
Buffalo 是 Go Web 框架，不能直接用前端 JS 压缩（如 Canvas 或 pica），所有压缩必须在服务端完成。Go 生态里稳定、支持批量、可控制质量的库只有 golang.org/x/image/draw + image/jpeg 组合，或更省心的 github.com/disintegration/imaging。
imaging 支持 resize + quality 控制，且对 PNG/JPEG/WebP 兼容好：
for _, fileHeader := range files {
src, err := fileHeader.Open()
if err != nil { continue }
img, _, err := image.Decode(src)
src.Close()
if err != nil { continue }
<pre class="brush:php;toolbar:false;">resized := imaging.Resize(img, 1200, 0, imaging.Lanczos)
outFile, _ := os.Create(filepath.Join("uploads", "compressed_"+fileHeader.Filename))
jpeg.Encode(outFile, resized, &jpeg.Options{Quality: 85})
outFile.Close()}
- 别用
imaging.Thumbnail——它会强制等比裁剪，破坏构图；用Resize+0高度保持宽高比 -
Quality: 85是 JPEG 的安全下限，低于 75 易出现明显块状噪点 - PNG 不支持 quality 参数，压缩得换思路：用
png.Encoder+ 减少色深，或走外部命令pngquant
并发压缩时 goroutine 泄漏和资源争用怎么防
直接对每个文件起 goroutine 跑 imaging.Resize 看似快，但图像解码/编码是 CPU 密集型操作，无限制并发会导致系统负载飙升、响应延迟暴涨，甚至被 Linux OOM killer 杀掉进程。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
必须加并发控制——用带缓冲的 channel 模拟 worker pool：
sem := make(chan struct{}, 4) // 最多 4 个并发
var wg sync.WaitGroup
for _, f := range files {
wg.Add(1)
go func(fh *multipart.FileHeader) {
defer wg.Done()
sem <- struct{}{} // 获取信号量
defer func() { <-sem }() // 释放
// ... 压缩逻辑
}(f)
}
wg.Wait()
-
4是经验值：一般服务器 CPU 核数 × 1～2，避免上下文切换开销反超收益 - 千万别用
runtime.GOMAXPROCS调整——图像处理不靠 goroutine 数量，靠实际 CPU 时间 - 临时文件路径要用
os.TempDir()或明确指定目录，避免多请求写同一文件名覆盖
压缩完怎么返回结果又不阻塞主线程
Buffalo 的 c.Render 或 c.JSON 是同步阻塞的，如果压缩耗时长（比如 100 张 4K 图），用户会看到浏览器转圈几十秒。真要体验好，得把压缩扔进后台，立刻返回任务 ID。
最轻量方案：用内存 map 存任务状态（仅开发/小流量适用）：
type Task struct {
ID string `json:"id"`
Status string `json:"status"` // "pending", "done", "failed"
Files []string `json:"files"`
Created time.Time `json:"created"`
}
tasks := make(map[string]*Task)
// 生成唯一 ID，存 task，启 goroutine 压缩，然后：
return c.JSON(202, map[string]string{"task_id": taskID, "status": "accepted"})
- 生产环境必须换成 Redis 或数据库存 task 状态，否则进程重启就丢任务
- 别在 goroutine 里直接调
c.Render——handler 已返回，response writer 已关闭 - 前端轮询
/api/task/:id拿进度，比 WebSocket 简单，也够用
真正难的不是写压缩逻辑，而是决定“压缩到什么程度算够”：电商主图要保细节，用户头像可激进降质，而截图类 PNG 压缩反而该优先删元数据而非改色深。这些策略没法套模板，得按业务切片配置。
