分片上传后文件合并需严格按编号顺序写入、校验完整性、确认全部到达且幂等防重。用FileStream.Seek()定位写入，避免内存溢出和原子性问题，合并前必须校验MD5、检查分片数量、加锁防并发，合并后及时清理临时文件。
分片上传后文件合并的典型流程
分片上传不是把所有 byte[] 拼起来就完事。服务器必须按顺序、无遗漏、校验完整，否则合并出的文件损坏。核心是：每个分片带编号（如 chunkIndex）、总片数（totalChunks）、唯一文件标识（如 fileId 或 uploadId），服务端收到后暂存到临时目录，等全部到位再顺序拼接。
如何安全合并分片到目标文件
不要用 File.AppendAllBytes() 直接追加——它不保证原子性，且无法控制写入位置；更不能靠分片名排序后 File.ReadAllBytes() 再 File.WriteAllBytes()，内存扛不住大文件。推荐用 FileStream 配合 Seek() 定位写入：
- 先创建目标文件（
File.Create(path)），获取空文件句柄 - 对每个已接收的分片，按
chunkIndex计算偏移量：offset = chunkIndex * chunkSize - 用
FileStream.Seek(offset, SeekOrigin.Begin)定位，再Write()写入该分片原始字节 - 写完一个分片后，不关闭流，继续下一个；全部写完再
Flush()和Close()
注意：chunkSize 必须与前端分片大小严格一致，否则偏移错位。最后一片长度可能小于 chunkSize，需用实际长度写入。
合并前必须做的三件事
跳过这些检查，90% 的“合并成功但文件打不开”问题都源于此：
-
校验分片完整性：每个分片应附带
md5或sha256，服务端收到后立即计算比对，失败则丢弃并返回错误 -
确认全部分片已到达：查数据库或 Redis 中该
fileId对应的已接收分片索引集合，确保count == totalChunks，缺一不可 -
防重复合并：合并操作必须幂等。可用文件锁（
FileStream.Lock()）或分布式锁（如 Redis SETNX），避免并发请求多次触发合并
临时分片存储与清理策略
分片文件不能长期留在磁盘。合并成功后要立刻清理，失败或超时也得删：
- 临时分片建议存在独立目录（如
"./uploads/chunks/"），路径含fileId避免冲突 - 为每个上传任务设超时（如 2 小时），用后台定时任务扫描
lastModified过期的分片目录并删除 - 合并失败时，除了删临时分片，还要在数据库中标记该
uploadId为failed，防止重试无限堆积
真正难的不是合并代码本身，而是状态一致性——分片到了没？校验过了没？别人是不是正在合并？这些逻辑漏掉任何一环，都会让“上传完成”变成假象。
