关键在于服务端可靠接收、校验、合并分片：按 file_id 和 chunk_index 写磁盘临时文件，用原子计数或 redis 跟踪已收分片，收到最后一片时校验 hash 后分批合并，提供 /upload/status 接口支持断点续传。
Go 服务端如何接收分片并合并文件
关键不是“怎么传”，而是“怎么接住、拼对、不丢片”。客户端分片后，每个 POST 请求应携带唯一 file_id、当前 chunk_index、总片数 total_chunks 和校验用的 chunk_hash（如 SHA256 前 8 字节）。服务端不做内存缓冲，直接写临时分片文件到磁盘，路径建议按 ./uploads/{file_id}/{chunk_index} 组织。
合并时机很关键：不能等所有请求发完才合并（客户端可能卡住），而应在收到最后一片时触发。但要注意——total_chunks 可能被伪造，更可靠的做法是用原子计数器记录已接收片数，配合 Redis 或本地并发安全 map + sync.Map 实现状态跟踪。
- 避免用
os.Create覆盖已有分片，改用os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_EXCL)防止重复写入导致数据错乱 - 合并前必须逐片校验
chunk_hash，跳过校验等于放弃完整性保障 - 大文件合并别用
io.Copy直接串连所有分片，容易 OOM；改用os.Open每片 +io.CopyN分批写入目标文件
客户端上传中断后如何恢复（断点续传逻辑）
断点续传的本质是“服务端可查询已传哪些片”。所以服务端必须提供一个轻量接口，比如 GET /api/v1/upload/status?file_id=abc123，返回类似 {"uploaded_chunks": [0,1,3,4], "total_chunks": 10}。客户端拿到后，只重传缺失的索引。
这个接口不能查数据库慢查，推荐把已传片索引存为 Redis 的 SET 类型（file_id:chunks），SISMEMBER 判断单片是否存在，SMEMBERS 拉全量，毫秒级响应。
立即学习“go语言免费学习笔记（深入）”；
- 客户端重试前必须先调用该接口，否则可能重复上传已存在分片，浪费带宽且增加服务端校验负担
- 不要依赖客户端本地缓存“上次传到哪”，网络不可靠，设备可能换、浏览器可能清缓存
- 如果服务端返回的
total_chunks和客户端初始值不一致，说明服务端被重置或有并发冲突，此时应整体重新协商上传（触发新file_id）
为什么用 multipart/form-data 而不是 raw body 传分片
不是不能用 raw，而是 multipart/form-data 提供了天然字段隔离和边界解析，让 Go 的 r.ParseMultipartForm() 能自动提取 file_id、chunk_index 等元数据，同时把文件流交给 r.MultipartForm.File["chunk"] 处理。如果用 raw，你得自己解析 HTTP body 边界、剥离 JSON 元数据、再截取二进制段——出错概率高，且标准库无内置支持。
-
ParseMultipartForm默认限制 32MB 内存缓冲，大分片会自动落盘，但需提前设r.ParseMultipartForm(32 ，否则超限直接报 <code>http: request body too large - 务必检查
r.MultipartForm.Value["file_id"]是否为空，空值意味着表单字段没传，不是文件问题，别直接去读文件流 - Chrome/Firefox 对单个
multipart请求大小有限制（通常 2GB），但实际受服务器配置（如 Nginx 的client_max_body_size）约束更强
并发上传分片时的文件锁与竞态问题
多个分片请求可能同时写同一个 file_id 下的不同分片文件，这本身没问题；但合并操作一旦触发，就可能和后续新来的分片写入冲突。典型现象是合并中途文件被删、或部分分片写了一半就被读走。
解决方案不是全局锁（吞吐暴跌），而是按 file_id 做细粒度互斥：用 sync.Map 存 file_id → *sync.Mutex，每次操作前 mu := getMutex(file_id); mu.Lock()。合并完成后记得从 map 中清理 mutex，避免内存泄漏。
- 千万别用
os.Rename替代原子写入——Windows 下 rename 不保证跨卷原子性，Linux 下虽可用但不如os.WriteFile配合os.O_CREATE|os.O_EXCL可靠 - 临时分片目录权限要设对，否则 worker 进程可能因 umask 导致其他用户可读，泄露上传内容
- 合并失败时，保留已传分片，记录错误日志并返回明确错误码（如
500 UploadMergeFailed），让客户端决定是重试合并还是放弃
真正难的不是实现分片，而是处理“片到了但元数据丢了”“合并中服务重启”“客户端以为成功其实服务端写磁盘失败”这些边缘情况。它们不会在 demo 里出现，但上线后第一个月必撞上。
