不能用c.FormFile处理边缘节点大文件上传，因其底层强制调用r.ParseMultipartForm(32MB默认阈值)，导致内存缓冲溢出或临时文件写失败；必须绕过multipart解析，直接流式读取raw body。
边缘计算节点资源有限，Gin 默认的 c.FormFile 和 r.ParseMultipartForm 在上传稍大文件（>10MB）时极易触发 OOM 或磁盘写失败——这不是配置调优能解决的问题，必须绕过 Gin 的 multipart 解析层，直接流式处理请求体。
为什么不能用 c.FormFile 处理边缘节点的大文件上传
它底层仍会调用 r.ParseMultipartForm(32 ，哪怕你设了 <code>router.MaxMultipartMemory = 8 。一旦 multipart body 中有超限文件，Go 运行时会尝试写入 <code>/tmp，而多数边缘设备（ARM 小盒子、工控机）根本没这个目录，或权限受限，直接报 http: no such file；更糟的是，ParseMultipartForm 会阻塞直到整个 body 被读完、解析完所有字段和文件，期间 goroutine 卡死，无法响应其他请求。
- 边缘设备内存通常 ≤4GB，
ParseMultipartForm的临时缓存 + 文件落盘缓冲极易吃光可用内存 -
/tmp在只读文件系统或无挂载的嵌入式 Linux 上不可写，导致上传直接失败 - 没有 timeout 控制，一个慢速上传就能拖垮整个节点 HTTP 服务
绕过 Gin multipart 解析，用 multipart.NewReader 流式收包
关键不是“怎么用 Gin”，而是“别让 Gin 解析 multipart”。你需要手动从 c.Request.Body 提取 boundary，再用标准库 multipart.NewReader 边读边处理，完全跳过 c.FormFile 和 c.MultipartForm。
- 先从
c.Request.Header.Get("Content-Type")提取 boundary：boundary := strings.TrimPrefix(contentType, "multipart/form-data; boundary=") - 创建 reader：
mr := multipart.NewReader(c.Request.Body, boundary) - 循环
mr.NextPart()，对每个 part 检查part.Header.Get("Content-Disposition")是否含name="file"，再用part.Open()得到io.Reader - 立刻用
io.CopyN(dstFile, partReader, expectedSize)写入磁盘，不缓存整块数据 - 普通表单字段（如
X-File-ID、X-Chunk-Index）需前端改用 header 传，或在 multipart body 中作为独立 part 手动解析
并发上传必须配信号量，且禁止复用 *os.File
边缘节点磁盘通常是 eMMC 或 microSD，IOPS 极低。盲目开 goroutine 并发写同一文件，不仅 offset 错乱，还会因频繁 seek 加剧磨损。正确做法是：按 chunk 顺序接收、顺序落盘，合并阶段再做。
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲 channel 当信号量：
sem := make(chan struct{}, 3)（SSD 边缘盒可设 4–6，eMMC 建议 ≤2） - 每个 chunk 接收后，起 goroutine 写入
chunk_001.bin、chunk_002.bin等独立临时文件，而非直接WriteAt到目标文件 - 绝不复用同一
*os.File句柄被多个 goroutine 同时WriteAt—— offset 不一致是必然的 - 合并时用
io.MultiWriter或顺序cat拼接，最后os.Rename原子替换
分片大小与校验必须适配边缘带宽和算力
边缘上传常走 4G/5G 或低带宽 LAN，网络抖动高；同时 CPU 算力弱（如 Cortex-A53），SHA256 全量校验开销大。分片不是越大越好。
- 推荐分片大小 1–2MB：太小（128KB）导致 syscall 过多，TCP 包碎片化严重；太大（10MB）则单次失败重传耗时长，且服务端 buffer 分配压力大
- 若需校验，客户端应在上传前算好每片 SHA256，随 header 发送
X-Chunk-SHA256；服务端只做比对，不重复计算 - 服务端收到 chunk 后，立即校验
Content-Length是否等于预期大小，防前端 bug 或恶意截断 - 中文/emoji 文件名一律转 UUID + 扩展名，避免不同边缘 OS（Buildroot/Yocto/Debian）对 UTF-8 文件名支持不一
最容易被忽略的是 cleanup：未完成上传的临时 chunk 文件必须定时清理，否则 SD 卡很快填满；而清理逻辑本身不能依赖 cron（边缘设备可能没这服务），得在 Gin 启动时启动一个 goroutine 定期扫描 /var/tmp/chunks/ 目录。
