生产环境文件上传必须处理大小限制、临时文件清理、MIME校验和并发安全，否则接口上线首日即可能被撑爆或绕过；Echo需手动调用ParseMultipartForm(32<<20)解析，否则c.FormFile将返回nil或panic。
直接用 echo.MultipartForm 读取文件、c.FormFile 获取元信息，再配合 file.Open 和 io.Copy 流式写入，就能跑通基础上传。但生产环境必须处理大小限制、临时文件清理、MIME校验和并发安全——这些不加，接口上线第一天就可能被撑爆或绕过。
如何正确解析 multipart/form-data 并提取文件
Echo 不像 Gin 那样自动调用 ParseMultipartForm，必须手动触发，否则 c.FormFile 返回 nil 或 panic。
- 在路由处理器开头显式调用
c.Request().ParseMultipartForm(32 ，参数是最大内存缓存（单位字节），建议设为 32MB；超过此值的文件部分会暂存到磁盘临时目录 -
c.FormFile("file")中的"file"必须与前端<input type="file" name="file">的name属性严格一致，大小写敏感 - 若表单含多个同名文件（如多选上传），需用
c.MultipartForm()获取整个*multipart.Form，再遍历form.File["file"]
为什么上传大文件时服务容易卡死或 500
根本原因是默认没有设置请求体大小上限，攻击者可发一个 2GB 的 POST 请求，把 Go 的 HTTP server worker 协程长时间占住，导致其他请求排队甚至超时。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 在 Echo 初始化时加中间件：
e.Use(middleware.BodyLimit("500M"))，硬性截断超限请求（注意单位是字符串，不是数字） - 避免在 handler 内用
bytes.Buffer全量读取文件——这会把整个文件加载进内存，100MB 文件 ≈ 100MB 堆内存占用 - 务必用
defer src.Close()和defer dst.Close()，漏掉任意一个都可能导致文件句柄泄漏，Linux 默认上限 1024，跑满后新请求直接失败
如何对接 Google Cloud Storage 或本地磁盘
本地写入用 os.Create 最简单，但要注意路径拼接和权限；对接 GCS 则必须用 storage.Client 的 Bucket.Object().NewWriter，不能直接传文件指针。
- 本地保存示例：
dst, err := os.Create("/tmp/upload_" + uuid.NewString() + filepath.Ext(f.Filename))，别直接用f.Filename当路径，防止路径穿越（如../../etc/passwd） - GCS 写入必须设
ContentType和ACL，否则默认私有且无 MIME 类型，前端直链访问会下载而非渲染 - 如果上传后需返回可公开访问 URL，GCS 推荐用 Signed URL（短期有效）而非公开 ACL，避免误配导致数据泄露
分片上传是否必须用 Echo 自定义中间件
不用。Echo 本身不提供分片逻辑，但你可以复用标准 http.Handler 模式，在路由里区分 /upload/init、/upload/chunk、/upload/merge 三个 endpoint，各自处理不同阶段。
- 关键不是框架能力，而是状态存储：用 Redis 记录
file_id → {total_chunks: 5, uploaded: [0,2,4]}，比用内存 map 更可靠 - 合并操作必须加分布式锁（如
redis.SET file_id:lock "1" NX EX 30），否则并发触发 merge 可能损坏最终文件 - 客户端计算的文件 hash（如
sha256）要在 init 阶段就存入状态，后续每个 chunk 上传时校验chunk_hash，防篡改
真正难的不是写通一个上传接口，而是当上传量从日均 10 次涨到 10 万次时，临时目录磁盘爆满、Redis 状态键没 TTL、GCS Writer 没设 ChunkSize 导致小文件写入慢十倍——这些问题不会报错，只会让系统越来越卡。留心那些没写进文档的默认行为，比写代码花的时间多得多。
