buffalo 默认不处理缩略图，因其专注数据流与权限等核心功能，缩略图属业务逻辑，需开发者按需集成图像库；上传接口必须手动解析 multipart 表单，否则文件为空。
Buffalo 是一个 Go 语言的全栈 Web 框架（不是 InsightFace 的 buffalo_l 模型），它自带路由、模板、ORM 和中间件支持，但不内置图片处理能力。实现「上传图片并自动生成缩略图」需要你手动集成图像处理库，并注意文件生命周期和路径安全。
为什么 Buffalo 默认不处理缩略图？
Buffalo 的 buffalo-pop 和 buffalo-auth 关注数据流与权限，文件上传只到 *multipart.FileHeader 层就停止了；缩略图属于业务逻辑层，框架认为该由开发者按需选型——比如用 golang.org/x/image 或 github.com/disintegration/imaging，而非强绑定。
上传接口必须显式解析 multipart 表单
Buffalo 不像 Express 或 Flask 那样自动解析 multipart/form-data。你得在 handler 里手动调用 r.ParseMultipartForm，否则 r.MultipartForm.File 为空。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 务必设置
MaxMemory（例如32 即 32MB），否则大文件会直接写临时磁盘，且无法控制位置 - 检查
err：常见错误是http: request body too large，需同步调整buffalo.App().Use(middleware.RequestID())前的http.MaxBytesReader - 别直接用
file.Open()—— 要用file.Open()返回的multipart.File，它是io.ReadCloser，需 defer.Close()
缩略图生成推荐用 imaging 库（非 resize）
github.com/disintegration/imaging 比标准库 image/* 更省心：自动识别格式、保持 EXIF 方向、支持裁剪/填充/质量控制。Buffalo 项目里直接 go get 即可，无需 CGO。
- 读取时用
imaging.Decode(f, imaging.AutoOrientation(true))处理手机竖拍旋转问题 - 生成缩略图建议用
imaging.Thumbnail(src, width, height, imaging.Lanczos)，不是Resize——Thumbnail会等比缩放+居中裁切，避免人脸被切掉 - 保存前检查目标目录是否存在：
os.MkdirAll("./public/uploads/thumbs", 0755)，路径必须相对buffalo dev启动目录，不是./ - 文件名别拼接原始名：用
uuid.NewString() + ".jpg"，防止../../../etc/passwd.jpg路径遍历
如何让缩略图 URL 可被浏览器直接访问？
Buffalo 的 public/ 目录是静态文件根路径，但默认不启用子目录自动索引。你生成的缩略图必须存进 public/uploads/thumbs/，然后确保 app.Use(pongo2.Param("ENV", "development")) 之外没禁用静态服务。
- 验证方式：启动后直接访问
http://localhost:3000/uploads/thumbs/abc123.jpg，返回 200 才算成功 - 不要用
app.GET("/thumb/:id", ...)动态代理——那会绕过 HTTP 缓存，且增加 Goroutine 开销 - 生产环境记得在 Nginx/Apache 里配置
location /uploads/thumbs的缓存头，例如expires 7d
真正容易被忽略的是：缩略图生成失败时，handler 不能只 log 错误然后返回空响应。用户上传后看到原图却没缩略图，会以为功能坏了——至少要返回带 thumb_url: "" 的 JSON，并在前端降级显示原图。
