必须先调用 ParseMultipartForm 才能访问文件和表单字段，因其采用懒解析机制——不显式调用则 r.FormFile、r.MultipartForm 等均为空或 panic；传 0 会 panic，必须传正整数（如 32<<20），且默认隐式阈值为 32MB。
为什么 ParseMultipartForm 是第一个必须绕开的坑
Go 标准库默认对 multipart/form-data 请求调用 r.ParseMultipartForm(32，这会把整个请求体（包括几 GB 的文件）先读进内存或临时磁盘——不是性能差的问题，是直接导致 OOM 或阻塞后续流式读取。一旦调用过，<code>r.Body 就被消费完，你再也拿不到原始字节流。
正确做法是：在 handler 开头立刻执行 r.ParseMultipartForm(0)，传 0 表示跳过内存缓存，让 r.MultipartReader() 或直接读 r.Body 成为可能。
- 别在中间件或公共函数里偷偷调用
ParseMultipartForm，它不可逆 - 如果前端发的是
application/octet-stream（推荐），压根不用碰 multipart，直接io.LimitReader(r.Body, chunkSize)截取分片 -
r.FormValue("chunkIndex")和r.URL.Query().Get("uploadId")要早于任何 Body 读取，否则 Form 解析会触发隐式ParseMultipartForm
如何安全接收分片并写入临时文件
每个分片请求只应写入对应位置的临时文件，不能靠 io.Copy 直接追加——那样无法保证顺序，也无法校验偏移。关键在于「按 chunkIndex 精确写入」+「防止并发覆盖」。
- 打开文件用
os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_EXCL, 0644)，O_EXCL确保不会意外覆盖已有分片 - 写入前先
f.Seek(int64(chunkIndex)*chunkSize, io.SeekStart)定位，再f.Write(data)；不要依赖上一次读写位置 - 如果服务端支持 Range 写入（如对象存储），优先用
PUT /object?uploadId=xxx&partNumber=5+Content-Range头，避免本地磁盘暂存 - 务必检查
n == len(data)，否则说明写入不完整，应返回 500 并清理该分片文件
客户端切片时 Blob.slice 比 FileReader.readAsArrayBuffer 更关键
前端不是“能不能切”，而是“怎么切才不崩”。用 FileReader.readAsArrayBuffer 把 2GB 文件全读进内存，浏览器直接卡死、GC 飙升、甚至崩溃——这不是兼容性问题，是内存模型决定的硬限制。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
file.slice(start, end)（返回新Blob），它是零拷贝的，内存占用恒定，与文件大小无关 - 每个分片请求 URL 带明确参数：
/upload/{uploadId}/chunk?index=12&total=47，别塞进 body 或 form data - Header 设为
Content-Type: application/octet-stream；若误设multipart/form-data却没提供boundary，服务端直接 400 - 加
X-Chunk-Hash: sha256-xxxxxx头，服务端边写边校验，失败立即中断，不落地再算
合并前排序和哈希校验缺一不可
合并不是按文件名字符串排序 chunk_1、chunk_10、chunk_2 —— 这会导致数据错乱。也不只是数文件个数够不够，最后一块的长度往往不足 chunkSize，必须重读校验。
- 遍历临时目录所有分片文件，用
strings.TrimSuffix(name, ".tmp")提取chunkIndex，转成int后数值排序 - 逐个
os.Open分片文件，用sha256.New()+io.Copy计算哈希，比对客户端X-Chunk-Hash，任一片失败就中止合并 - 目标文件用
os.OpenFile(finalPath, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)创建，然后io.Copy(f, chunkFile)追加 - 合并完成后，重新打开 final 文件计算总哈希，对比客户端传的
X-Final-SHA256；不匹配就立刻os.RemoveAll(tempDir)，不留脏数据
