Echo高并发上传卡住因默认调用ParseMultipartForm同步阻塞读取整个multipart body；应禁用自动解析，改用mime/multipart.NewReader流式处理原始body，边读边存并设读取超时。
为什么 Echo 默认处理文件上传会卡住高并发
因为 echo.Context.FormFile 底层调用的是 http.Request.ParseMultipartForm，它会把整个 multipart body 一次性读进内存或临时磁盘文件，且全程同步阻塞。当并发上传请求增多（比如 500+ RPS），大量 goroutine 会在 ParseMultipartForm 或后续的 file.Open、io.Copy 上等待 I/O，导致连接堆积、超时频发，甚至触发 runtime.gopark 卡死。
必须禁用默认的 multipart 解析，改用流式读取
别让 Echo 自动解析 multipart/form-data —— 它在高并发下既浪费内存又不可控。正确做法是手动接管原始 body 流：
- 调用
c.Request().Body获取裸io.ReadCloser - 用
mime/multipart.NewReader边读边解析，不缓存整块数据 - 对每个
multipart.Part，立即写入目标（如本地磁盘、S3、或分片缓存） - 务必设置
Request.Body的读取超时，避免恶意大文件拖垮连接
示例关键片段：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
func uploadHandler(c echo.Context) error {
// 禁用自动解析
c.Request().ParseMultipartForm(1 << 20) // 仅预留1MB内存用于边界解析，不存文件内容
mr, err := mime.NewMultipartReader(c.Request().Body, c.Request().MultipartForm.Parts[0].Header)
if err != nil {
return err
}
for {
part, err := mr.NextPart()
if err == io.EOF {
break
}
if part.FormName() == "file" {
// 直接流式写入，不落地临时文件
dst, _ := os.Create("/tmp/" + part.FileName())
io.Copy(dst, part)
dst.Close()
}
}
return c.String(http.StatusOK, "ok")
}
上传路径不能走本地磁盘直写，要异步落盘或直传对象存储
即使流式读取，如果每次上传都同步 os.WriteFile 或 io.Copy 到本地磁盘，I/O 仍是瓶颈。尤其当磁盘为机械盘或共享云盘时，move_uploaded_file 类操作在高并发下会迅速打满 IOPS。
- 小文件（sync.Pool 复用
bytes.Buffer，内存暂存后异步刷盘 - 中大文件（≥5MB）：跳过本地中转，用
minio-go或aws-sdk-go直传 OSS/S3，配合PutObject的 streaming 模式 - 必须配
context.WithTimeout控制单次上传最大耗时，防止长尾请求拖累整个队列
别忽略 Echo 的中间件和 Context 生命周期陷阱
很多开发者在 echo.MiddlewareFunc 里提前调用 c.Request().ParseMultipartForm，或者把整个 *multipart.FileHeader 存进 c.Set()，这会导致：
- Context 被大对象（如未释放的
file.Header）长期持有，GC 压力上升 - 中间件执行完后，
c.Request().Body已被读空，后续 handler 拿不到原始流 - 没设
echo.HTTPErrorHandler统一捕获multipart.ErrMessageTooLarge，错误直接 500
真正安全的做法是：只在最终 handler 里按需解析，且解析后立刻释放资源（part.Close()、dst.Close()），不在 Context 中保留任何文件句柄或大字节切片。
