必须限制 formfile 内存使用，因其默认将整个文件读入内存，易致服务崩溃；需设 e.maxmultipartmemory、校验 mime 类型、控制临时存储并添加超时。
直接用 FormFile 处理大视频上传，不加限制会吃光内存、拖垮服务，甚至被恶意上传打穿。必须做大小限制、临时存储控制和 MIME 校验。
echo.Context.FormFile 为什么不能直接用于生产上传
FormFile 底层调用的是 http.Request.FormFile，它会把整个文件读进内存（multipart.Reader 默认无缓冲），遇到几百 MB 的视频，单个请求就可能占掉几百 MB 内存。更危险的是：没设超时、没验类型、没限大小，攻击者发个 10GB 的空文件就能让服务卡死。
- 默认不限制
maxMemory，全部塞进bytes.Buffer - 不校验
Content-Type，.exe改后缀传成video/mp4就过掉了 - 没有上传进度感知，客户端断连后服务端还在等数据
设置 multipart.MaxMemory 和自定义 FormFile 流程
Echo 本身不接管 multipart 解析逻辑，得靠 e.MaxMultipartMemory 提前设上限。这个值不是“单文件最大”，而是「整个表单解析阶段允许使用的内存总量」，包括所有字段+文件头+文件内容缓存。
- 设太小（如
4 即 4MB）：大视频直接报 <code>http: request body too large - 设太大（如
100 ）：并发 10 个 50MB 视频上传，瞬间吃掉 1GB 内存 - 推荐值：
16 （16MB），配合后续流式写入磁盘，只留 header 和小文件在内存
示例：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
e := echo.New()
e.MaxMultipartMemory = 16
<h3>校验文件 MIME 类型和扩展名的可靠方式</h3>
<p>仅靠 <code>file.Header.Get("Content-Type")</code> 不可信——浏览器可伪造，<code>curl -F 'video=@a.exe;type=video/mp4'</code> 就能绕过。必须读取文件前几个字节（magic bytes）比对。</p>
- 用
file.Open()得到io.ReadCloser，再用io.LimitReader取前 512 字节 - 传给
http.DetectContentType或更准的github.com/h2non/filetype - 同时检查扩展名是否在白名单中（
.mp4、.mov、.webm） - 注意：不要用
path.Ext(file.Filename)判定类型，xxx.mp4.exe会返回.exe
关键判断逻辑片段：
src, _ := file.Open()
defer src.Close()
buf := make([]byte, 512)
_, _ = src.Read(buf)
contentType := http.DetectContentType(buf)
if !strings.HasPrefix(contentType, "video/") {
return echo.NewHTTPError(http.StatusBadRequest, "not a video file")
}
上传超时与客户端断连处理
Echo 默认使用 Go 标准库的 http.Server，它的 ReadTimeout 对 multipart 上传无效——因为 ReadTimeout 只重置于每个请求头开始，而大文件上传过程中 TCP 连接一直开着，超时不会触发。
- 必须显式设置
http.Server.ReadHeaderTimeout（控制 headers 解析时间）和ReadTimeout（已弃用，但部分旧版仍生效） - 更稳妥的是用
context.WithTimeout包裹 handler，比如c.Request().WithContext(context.WithTimeout(c.Request().Context(), 300*time.Second)) - 客户端断连时，
io.Copy会立即返回read: connection reset by peer，需捕获并清理临时文件
容易被忽略的一点：上传中途失败，os.Create 创建的临时文件不会自动删除，必须用 defer os.Remove 或 tempfile 配合 os.Rename 原子提交。
