c.FormFile("file")只取第一个文件，因内部仅访问MultipartForm.File"file"；正确做法是直接读取c.Request().MultipartForm.File["file"]切片，并用io.Copy流式处理文件，同时需手动设置MaxBytesReader防绕过限流。
直接用 c.FormFile() 或前端拖拽发来的 multipart/form-data 请求，Echo 本身不提供上传 UI 组件，但能稳定承接——关键在后端解析逻辑是否绕过常见陷阱。
为什么 c.FormFile("file") 总是只拿到第一个文件？
浏览器拖拽多个文件时，会把它们打包进同名字段（如 file），生成多个 multipart part。而 c.FormFile("file") 内部只取 MultipartForm.File["file"][0]，其余被忽略。
- 正确做法是直接访问
c.Request().MultipartForm.File["file"]，它是一个[]*multipart.FileHeader切片，长度即为拖入文件数 - 每个
FileHeader包含Filename、Size、Header，可用于校验类型（Header.Get("Content-Type")）和大小 - 别用
io.ReadAll(src)读整个文件到内存；应调用header.Open()后用io.Copy()流式写入磁盘或对象存储
e.MaxRequestBodySize 为什么经常失效？
这个配置只在请求进入路由匹配前生效。一旦 handler 或中间件提前读取了 r.Body（比如调了 c.FormFile()、c.MultipartForm() 或 c.Bind()），原始 body 就被清空，限流就形同虚设。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 必须在 handler 开头第一行手动包装：
c.Request().Body = http.MaxBytesReader(c.Response(), c.Request().Body, 10*1024*1024)（10MB） - 注意单位是字节，Go 不支持
10MB这类字面量写法 - 若需支持大文件分片上传，得禁用自动解析：
c.Request().ParseMultipartForm(0)，否则c.FormFile()会吞掉原始流 - 仅限制总大小还不够：攻击者可构造 1KB 文本字段 + 99MB 文件绕过，所以还要配合
ParseMultipartForm(maxMemory)控制内存缓冲上限（如8 ）
如何安全服务用户上传的视频文件？
e.Static("/uploads", "uploads") 不适合大文件，它依赖 http.FileServer 的默认行为，容易因内存缓冲或超时导致连接中断（ERR_CONNECTION_RESET）。
- 改用
c.File(filepath)，它调用http.ServeContent，支持Range请求、断点续传、Accept-Ranges: bytes和流式io.Copy - 务必校验
filename：禁止".."、开头为"/"或以"."开头，防止路径遍历 - 确保文件路径拼接使用
filepath.Join()，而非字符串拼接 - 若仍中断，需同步调整 Echo Server 的超时配置：
e.Server.ReadTimeout、WriteTimeout，并检查反向代理（如 Nginx）的超时设置
真正难的不是写对一行 c.File()，而是所有校验和限流都得落在「解析 multipart 之前」——顺序错了，再全的检查也白搭。
