因为 multipart.Form 解析时默认将文件写入磁盘或内存缓冲，FileHeader.Size 仅在调用 form.File["key"] 后才可用，无法前置校验；须在 ParseMultipartForm 前设置 MaxMultipartMemory 控制内存阈值。
为什么 echo.MultipartForm 无法直接拿到文件大小？
因为 Go 标准库的 multipart.Form 在解析时默认会把文件先写入临时磁盘（/tmp）或内存缓冲，直到调用 form.File["key"] 才返回 *multipart.FileHeader——此时文件已部分或全部读取，FileHeader.Size 虽然存在，但无法在真正读取前拦截超限上传。直接依赖它做前置校验会失效。
必须在 ParseMultipartForm 前设置 MaxMemory 和 MaxMultipartMemory
Echo 底层复用 http.Request.ParseMultipartForm，而该方法受 request.ParseMultipartForm(maxMemory int64) 控制：它决定多少字节以内留在内存、超出后写入临时文件。但 Echo 默认不设限，导致大文件直接冲进磁盘，失去控制权。
实操建议：
- 在 Echo 启动前，通过
e.MaxMultipartMemory = 8 （例如 8MB）全局限制单次 multipart 解析的内存上限 - 这个值必须小于你期望拦截的文件大小阈值；比如要拦 10MB 文件，就设成
9 或更小，否则超限部分仍会落盘且不报错 - 注意：该设置只影响内存缓冲区，不等于最终文件大小上限——它只是触发错误的“开关”
用中间件在 c.MultipartForm() 前检查 Content-Length
Content-Length 是 HTTP 请求头里最直接的总长度标识，虽然可被伪造，但在内网或可信代理后足够用于快速拒绝明显超限请求。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
实操建议：
- 在路由 handler 前加中间件，读取
c.Request().Header.Get("Content-Length") - 转换为
int64后与你的阈值（如10 * 1024 * 1024）比较，超限直接返回413 Payload Too Large - 注意：该头在分块传输（chunked encoding）时不存在，此时需回退到后续解析逻辑；但 Echo 默认不支持自动处理 chunked 表单上传，实际中多数客户端仍发
Content-Length - 示例判断：
if cl := c.Request().Header.Get("Content-Length"); cl != "" { if size, err := strconv.ParseInt(cl, 10, 64); err == nil && size > 10*1024*1024 { return echo.NewHTTPError(http.StatusRequestEntityTooLarge, "file too large") } }
真正可靠的检测必须结合 c.FormFile() + FileHeader.Size + 提前关闭
最稳妥的方式是让 Echo 解析表单，拿到 *multipart.FileHeader，检查其 Size 字段，再决定是否继续打开文件句柄。关键点在于：不调用 c.SaveToFile() 或 file.Open() 就不会真正读取内容，开销极小。
实操建议：
- 调用
file, err := c.FormFile("upload")获取 header，此时尚未读文件体 - 立即检查
file.Size，超限就直接返回错误，避免后续操作 - 如果通过，再用
src, _ := file.Open()获取 reader —— 此时才开始流式读取，可控 - 注意：某些浏览器在多文件上传时可能合并
Content-Length，所以仅靠头检测不可靠；必须走到这一步才算落地校验
真正的难点不在代码行数，而在理解 Go multipart 解析生命周期和 Echo 封装层级之间的缝隙——MaxMultipartMemory 控制解析起点，Content-Length 提供快速过滤，FileHeader.Size 才是唯一可信的文件元信息。三者缺一不可，且顺序不能颠倒。
