根本原因是请求未被识别为multipart表单：前端form必须设enctype="multipart/form-data"，请求头需含Content-Type: multipart/form-data; boundary=...，字段名大小写须完全匹配，且Body不能被中间件提前读取。
Echo 框架上传失败，90% 是因为没配对 Content-Type 和 enctype，不是框架问题，是 HTTP 协议层没走通。
为什么 c.FormFile() 总是返回 nil 或报 http.ErrNotMultipart
根本原因是请求压根没被识别为 multipart 表单。Echo 不会“猜”你传的是文件——它严格依赖标准 HTTP 头和表单属性：
- 前端
<form>必须显式声明enctype="multipart/form-data"，漏掉就等同于普通 POST，c.FormFile()必然为空 - 请求头必须含
Content-Type: multipart/form-data; boundary=...，手动发请求（如 curl / Postman）时若没设，或用 fetch 但没让浏览器自动生成 boundary，就会触发http.ErrNotMultipart - 字段名大小写敏感：前端传
file，后端必须用c.FormFile("file")，写成"File"或"FILE"就查不到 - 如果中间件（比如日志、鉴权）提前调用了
c.Request.Body.Read()，Body 流已被消费，后续c.FormFile()就读不到任何内容
ParseMultipartForm 参数设多少才安全
ParseMultipartForm 的参数（如 c.Request.ParseMultipartForm(32 ）不是“最大上传体积”，而是“非文件字段（text inputs、checkboxes 等）在内存中缓存的上限”。超过这个值，Go 会把那些字段临时写入磁盘，但文件部分不受影响。
常见误操作：
- 设太小（如 1KB）：表单里带长描述文本就触发磁盘写入，没必要
- 设太大（如 1GB）：无意义，且可能掩盖真实瓶颈（比如代理超时或内存压力）
- 重复调用：Echo 默认已在内部调一次（默认 32MB），你在 handler 里再显式调就会 panic “Part already parsed”
建议保持默认，除非你明确知道表单里非文件字段会超 32MB —— 这种场景本身就很可疑。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
c.File() 服务大视频时为啥用 e.Static() 就中断
e.Static() 底层用的是 http.FileServer，它不主动调用 http.ServeContent，也不做流式 io.Copy 控制，遇到大文件容易卡在内存缓冲或超时阶段，表现为浏览器加载到一半断开、ERR_CONNECTION_RESET 或 net::ERR_INCOMPLETE_CHUNKED_ENCODING。
正确做法是用 c.File()（推荐）或 e.File()：
- 它们调用
http.ServeContent，自动支持Accept-Ranges: bytes、Content-Length和条件响应，视频拖拽进度条（Seek）才真正可用 - 路径必须校验：若用
c.Param("filename")，务必检查是否含".."或开头为"/"，否则可能被利用读取任意文件 - 注意 Echo Server 自身超时设置：
e.Server.ReadTimeout和WriteTimeout默认 30 秒，50MB 视频在慢网下很可能超时，需按需延长
想监控上传进度？别碰 c.MultipartForm()
c.MultipartForm() 是“全有或全无”的一次性解析，上传完成才返回结果，中间过程完全不可见。进度监控必须绕过它，自己接管 c.Request.Body：
- 先读
c.Request.Header.Get("Content-Length")获取总大小（客户端未发该 header 则 fallback 到 -1） - 用自定义
ProgressReader包装原始 Body，在每次Read()时更新全局状态（如sync.Map存 uploadID → 已读字节数） - 用这个包装后的 Body 初始化
multipart.NewReader()，再逐个NextPart()解析 —— 这样每读一块，进度就实时可查 - 绝对不要在同一个请求里既调
c.FormFile()又想自己读 Body，二者互斥
真正的难点不在代码，而在于前端如何配合轮询或 WebSocket 订阅这个 uploadID 对应的状态；服务端状态也得考虑超时清理，否则 sync.Map 会持续膨胀。
