buffalo需用中间件结合content-length检查与http.maxbytesreader双重拦截上传文件：前者快速返回413，后者防止内存溢出；还需魔数校验文件真实类型并妥善处理重渲染时的文件状态。
Buffalo 默认不校验上传文件的大小和类型，直接解析 multipart 表单会导致内存暴涨、服务卡死甚至 panic——必须在请求体读取前拦截并控制边界。
用中间件限制上传文件大小（Content-Length + MaxBytesReader）
仅靠 Content-Length 头判断不可靠（可伪造），但它是最快前置拦截手段；真正防内存溢出得靠 http.MaxBytesReader 包装 Request.Body。
- 在
app.go的app.Use()调用前插入中间件，检查c.Request().Header.Get("Content-Length") - 若值大于阈值（如 10MB =
10_485_760），立即返回c.Error(413, errors.New("request entity too large"))，不调c.Next() - 更关键的是后续包装：
c.Request().Body = http.MaxBytesReader(c.Response(), c.Request().Body, 10_485_760)，这行必须在c.Next()前执行 - 注意：此方式会让
ParseMultipartForm在读取超限时抛出http: request body too large，handler 需捕获该错误，不能只依赖 413 返回
用文件头魔数校验真实类型（非扩展名）
用户改后缀（如 evil.exe → evil.jpg）绕过前端校验很常见，必须读取文件头几个字节比对 magic number。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 调用
c.File("avatar")获取*multipart.FileHeader，再用f.Open()打开文件流 - 用
io.ReadFull(f, head[:])读前 16 字节（head := make([]byte, 16)），避免短读 - 比对时用已知魔数，例如 PNG 是
[]byte{0x89, 0x50, 0x4E, 0x47}，JPEG 是[]byte{0xFF, 0xD8, 0xFF} - 若
err == io.ErrUnexpectedEOF，说明文件太小无法校验，应拒绝（c.Error(400, "file too small for magic check")）
表单绑定后重渲染时保留上传文件状态
验证失败后调 c.Render(200, r.HTML("form.html")) 会丢失原始文件数据——因为 multipart.FileHeader 不是普通字段，不会被自动存入 context。
- 必须显式调
c.Set("file_header", f)（f是*multipart.FileHeader） - 模板中不能直接用
{{.file_header.Filename}}，需在 handler 中先打开文件流或提取元信息再传入 - 更稳妥的做法是：验证失败时把文件保存到临时路径（带唯一前缀），再将路径存入 context，重渲染时通过该路径回显文件名（不重新上传）
- 别忘了清理临时文件，可在 handler 结尾或中间件里用
defer os.Remove(tempPath)
魔数校验和 MaxBytesReader 必须配合使用：前者防恶意文件执行，后者防 DoS。单独做任一者都留有明显缺口。
