e.MaxRequestBodySize 无法阻止 multipart 临时文件写入磁盘，因其仅限制请求体总大小，不干预 ParseMultipartForm 的自动落盘行为；临时文件默认存于系统 Temp 目录且需手动 Close + Remove。
为什么 Echo 的 e.MaxRequestBodySize 挺不住 multipart 上传的临时文件
因为 e.MaxRequestBodySize 只限制整个请求体字节数，不干预解析过程。一旦请求通过该限制，c.MultipartForm() 或 c.FormFile() 调用时，Go 标准库会自动调用 ParseMultipartForm，并默认把文件写入 os.TempDir()（通常是 C:\Users\...\AppData\Local\Temp 或 /tmp），且不会自动清理。
攻击者可以构造一个 1KB 表单 + 9.99MB 文件，总大小刚好卡在限值内——框架放行，但 9.99MB 临时文件已落地磁盘，反复提交就撑爆磁盘。
-
ParseMultipartForm内部使用tempfile创建文件，路径不可控，也不受 Echo 中间件拦截 - 即使你没显式调用
c.FormFile()，只要Content-Type: multipart/form-data且未禁用解析，部分中间件或日志记录逻辑可能触发隐式解析 - 临时文件生命周期完全脱离 Echo 控制，除非你手动清理或依赖系统定时轮转
必须在 handler 里显式调用 os.Remove 清理 c.FormFile() 返回的临时文件
Go 的 multipart.File 接口底层是 *os.File，它指向一个真实磁盘文件。Echo 不会帮你关掉或删掉它——这是你的责任。
典型错误写法：c.FormFile("avatar") 拿到文件后直接读取、保存、返回，却忘了 defer file.Close() 和 os.Remove(file.Filename)。
- 必须先
file.Close()，否则 Windows 下可能因句柄占用导致Remove失败 -
file.Filename是临时路径（如C:\Users\...\Temp\23456789），不是原始上传名，可直接传给os.Remove - 若上传多个文件，每个都要单独
Close()+Remove()；哪怕只取一个，其余仍留在磁盘
示例片段：
file, header, err := c.FormFile("file")
if err != nil {
return c.JSON(400, "upload error")
}
defer file.Close() // 必须
// ... 保存到目标位置
if err := os.Remove(file.Filename); err != nil {
log.Printf("failed to remove temp file %s: %v", file.Filename, err)
}
更安全的做法：用 io.Copy 流式处理，跳过落地临时文件
如果你不需要原始文件句柄（比如只是校验哈希、转存到对象存储、或转成内存 buffer），就别让 Go 写临时文件——改用 c.MultipartForm() 后从 form.File 获取 multipart.File，再用 io.Copy 直接流转走。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
关键点：ParseMultipartForm(32 的第一个参数是内存阈值，设为 <code>0 或很小值（如 1），就能强制所有内容进内存，避免写磁盘。
- 设
ParseMultipartForm(0)：全部进内存，适合小文件（http: request body too large - 设
ParseMultipartForm(1 （1MB）：小于 1MB 进内存，大于则落盘——但你仍需清理落盘文件 - 流式处理时，
file是io.Reader，无需os.Remove，也无临时文件生成
示例（内存优先）：
err := c.Request.ParseMultipartForm(0) // 强制全内存
if err != nil {
return c.JSON(400, "parse error")
}
form, _ := c.MultipartForm()
for _, files := range form.File {
for _, file := range files {
src, _ := file.Open()
defer src.Close()
// io.Copy(dst, src) → 直接转发，不落地
}
}
全局清理风险高，不建议依赖 os.RemoveAll(os.TempDir())
有人想“一劳永逸”，在服务启动时清空 os.TempDir()。这非常危险：其他进程（包括系统更新、杀毒软件、甚至另一个 Go 服务）也在用这个目录，RemoveAll 极可能误删正在使用的文件，导致崩溃或数据丢失。
真正可控的方式只有两种：
- 每个 handler 显式清理自己拿到的
file.Filename - 用独立子目录 + 定期
find清理（Linux/macOS）或forfiles（Windows），按修改时间删 >24h 的文件，且限定在你自己的临时子目录下（如/tmp/myapp_uploads）
复杂点在于：临时文件路径不可配置，也不带业务前缀。所以最稳的实践是——别让它产生，或者产生后立刻亲手删掉。没人替你善后。
