Echo框架无法通过c.FormFile()或c.MultipartForm()实现上传进度监控，因其一次性读取完整请求体；需手动接管Request.Body，用ProgressReader包装并结合multipart.NewReader()流式解析，同时注意Content-Length、uploadID绑定与sync.Map清理。
Echo 框架本身不提供上传进度监控能力，c.FormFile() 和 c.MultipartForm() 都是一次性读取完整请求体，无法中途获取已接收字节数——这是底层设计决定的，不是配置问题。
为什么 c.FormFile() 返回时上传早已完成
调用 c.FormFile("xxx") 会触发 Echo 内部对 c.Request.Body 的完整读取（直到 EOF 或超时），所有数据被暂存到内存或临时磁盘文件中。此时：
- 客户端发送的整个 multipart 请求体已被消耗，
Body不可再读 - 你拿到的
*multipart.FileHeader只包含元信息（Filenname、Size、Header），Size是解析后得到的，不是实时流式统计 - 若上传中断或超时，错误发生在读取阶段，但你无法在中间捕获“当前已传 32%”这类状态
想支持大文件上传且不丢进度，必须手动接管 Request.Body
绕过 c.FormFile()，直接用 multipart.NewReader() 解析原始流，并用自定义 io.Reader 包装 c.Request.Body 来统计进度：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 先从
c.Request.Header.Get("Content-Length")获取总大小（注意：前端必须发该 header；若缺失，只能设为 -1） - 构造一个
ProgressReader，内嵌原始Body，在Read(p []byte)中累加已读字节数，并写入sync.Map（key 为 uploadID） - 用该
ProgressReader初始化multipart.NewReader()，再循环NextPart()逐个解析字段和文件 - 禁止调用
c.ParseMultipartForm()或任何会触发自动 Body 读取的方法，否则你的包装器会被跳过
c.MultipartForm() 为何完全不可用于进度监控
c.MultipartForm() 底层调用的是 http.Request.ParseMultipartForm()，它会强制一次性读取全部 Body 到内存（或 MaxMemory 限制的缓冲区），超出部分落盘。这意味着：
- 你无法在读取过程中插入回调或统计逻辑
- 上传未完成前，
c.MultipartForm()会阻塞，直到整个请求体就位或失败 - 即使你提前读了部分 Body，
c.MultipartForm()仍会尝试重新读取，导致http: invalid byte in body等错误 - 对超大文件（如视频），极易触发
http: request body too large，而你连当前进度都看不到
实际部署时最易忽略的三个点
进度监控能跑通，不等于线上可用：
- 前端必须显式设置
Content-Lengthheader，Fetch API 默认不发，需用new Blob([file])构造并手动 set；XMLHttpRequest通常自带，但某些代理可能剥离 - uploadID 不能只靠时间戳或随机字符串，需绑定 session 或 JWT claim，否则并发上传时状态互相覆盖
- sync.Map 存储的状态要配 TTL 清理（比如 10 分钟无更新自动删除），否则内存持续增长，尤其在长连接或轮询场景下
