Echo框架上传接口调用流程-Golang-PHP中文网

c.multipartform()无法用于进度监控，因其一次性读取整个request.body且不暴露中间字节流过程，上传完成才返回，大文件还可能触发body too large错误；必须用progressreader包装body手动解析multipart。

echo框架上传接口调用流程

上传接口为什么不能直接用 `c.MultipartForm()`

因为 c.MultipartForm() 会一次性读完 Request.Body，中间不暴露字节流过程。你根本拿不到“已读多少”——等它返回时，文件早已传完，进度监控彻底失效。更糟的是，大文件可能触发 http: request body too large 错误，而你连错误发生前的上传量都看不到。

必须手动包装 `Request.Body` 才能获取进度

标准库 http.Request 的 Body 是个 io.ReadCloser，你可以用自定义 io.Reader（比如 io.TeeReader 或带计数的 ProgressReader）包装它，在每次 Read() 时累加字节数，并同步写入状态存储（如内存 map 或 Redis）。

Echo框架 5.1.0

Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。

下载

别直接调 c.Request().ParseMultipartForm()，它也会吃掉整个 Body
先用 bytes.Buffer 或 io.MultiReader 把原始 Body 缓存一份，再用 ProgressReader 包装它供后续解析使用
上传状态 key 建议用 upload:uuid，避免路径或 IP 冲突；值存 map[string]int64{"total": 1024000, "done": 32768}
客户端需轮询 /api/upload/status?uuid=xxx，服务端从共享存储查当前进度并返回 JSON

`c.FormFile()` 和 `c.MultipartForm()` 的调用时机差异

两者都依赖 Request.Body 的完整读取，但触发点不同：c.FormFile() 是懒加载，只在首次调用时才真正解析 multipart；c.MultipartForm() 则是显式强制解析。无论哪种，只要调用过一次，Body 就被耗尽，后续再读就是空。

如果你在中间件里提前调了 c.MultipartForm()，handler 里再调 c.FormFile() 会返回 nil, nil，不是报错而是静默失败
想兼容已有逻辑？只能在中间件里把 Body 替换为可重放的 io.NopCloser(bytes.NewReader(buf.Bytes()))
注意：buf 必须足够大，否则大文件上传会 OOM；建议配合 io.LimitReader 截断日志体，只缓存前几 KB

为什么 WebSocket 推送比轮询更可靠

轮询有延迟、浪费连接、难保序；WebSocket 能在读取过程中实时 c.WebSocket().WriteMessage() 推送进度，但前提是你的上传流不能被框架自动 consume。

必须绕过 Echo 默认的 Bind 和 MultipartForm 流程，自己用 c.Request().Body 构建 multipart.Reader
每解析出一个 part，就用 io.Copy + 进度回调写入目标文件，同时向该连接的 WS channel 发送结构化进度消息
别在 handler 里开 goroutine 处理 WS 推送——要确保和 Body 读取在同一个 goroutine，否则并发读 Body 会 panic