大文件分片上传需客户端显式传递文件guid、chunkIndex、totalChunks和chunkHash，固定4MB块大小，用SHA256校验，断点续传依赖服务端GET接口返回已传块列表，合并时流式写入并逐块校验。
大文件分片上传必须自己管理块序号和校验
直接用 HttpClient 发起多个并发 POST 请求本身不难，难点在于服务端无法自动识别哪块是哪块、是否重复、是否丢失。C# 客户端必须显式传递唯一标识（如文件 guid）、当前块索引（chunkIndex）、总块数（totalChunks）和块哈希（chunkHash），否则后端无法安全合并。
常见错误是只传 chunkIndex 不传 guid，导致不同用户上传同名文件时块混在一起；或跳过哈希校验，结果网络传输中某块被静默损坏，合并后文件打开失败但无提示。
- 用
Path.GetTempFileName()为每个上传任务生成临时guid，全程复用，不依赖文件名 - 块大小建议固定为
4 * 1024 * 1024（4MB），太小增加 HTTP 开销，太大内存压力高且重传成本高 - 计算块哈希用
SHA256.HashData(chunkBytes)，别用MD5—— .NET 6+ 中MD5已标记为不安全
断点续传靠服务端返回已上传块列表，不是客户端“记住”
客户端本地记录已传块（比如写进 upload_state.json）极不可靠：程序崩溃、磁盘满、用户删了临时文件，状态就丢了。真正健壮的断点续传，是每次上传前先发一个 GET /api/upload/chunks?fileId=xxx，让服务端返回它数据库里已存的 chunkIndex 列表。
这个接口必须幂等、轻量、带缓存头。如果服务端没实现这个接口，所谓“断点续传”只是心理安慰。
- 请求该接口时加
If-None-Match头，服务端用ETag缓存响应（例如ETag: "chunks-{fileId}-v1"） - 客户端收到
304 Not Modified就复用上次的块列表，避免重复拉取 - 若返回
200，解析 JSON 数组如[0,2,4,5]，跳过这些索引，只上传缺失的块（如 1,3,6…）
合并文件块必须用 FileStream 流式写入，禁用 File.WriteAllBytes
把所有块读进内存再拼成一个 byte[] 合并，1GB 文件 ≈ 1GB 内存占用，极易触发 OutOfMemoryException。正确做法是打开目标文件的 FileStream，按块索引顺序逐个打开对应临时块文件，用 stream.Write(chunkBytes, 0, chunkBytes.Length) 追加写入。
注意：块文件不能用 File.ReadAllText 或 File.ReadAllBytes 加载，必须用 FileStream + BufferedStream 控制内存占用。
- 合并前先校验每块哈希，任一块不匹配就抛异常，不继续合并
- 用
FileMode.Create打开目标文件，确保旧文件被清空；用FileAccess.Write和FileShare.None防止并发写冲突 - 块文件合并完立刻
File.Delete(chunkPath)，别等“清理任务”——进程退出时未删干净会导致磁盘占满
.NET 6+ 推荐用 IAsyncEnumerable<byte[]> 做流式分片读取
传统 FileStream.Read 配合 while 循环容易出边界错误（比如最后一块不足 4MB 时多读 0 字节）。.NET 6 引入的异步可枚举流更安全：
async IAsyncEnumerable<byte[]> ReadChunks(string filePath, int chunkSize = 4 * 1024 * 1024)
{
await using var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, true);
var buffer = new byte[chunkSize];
int bytesRead;
while ((bytesRead = await fs.ReadAsync(buffer, CancellationToken.None)) > 0)
{
yield return bytesRead == buffer.Length
? buffer.Clone() as byte[]
: buffer.Take(bytesRead).ToArray();
}
}关键点：每次 yield return 都是新数组，避免后续修改影响前序块；buffer.Clone() 比 new byte[buffer.Length] 更快；FileOptions.Asynchronous 必须传 true，否则 ReadAsync 只是同步包装。
这个模式天然支持取消（传 CancellationToken）、进度回调（在 yield 前更新 UI）、以及与 IProgress<int> 集成——但别在 yield 里做耗时操作，会卡住整个枚举。
最易被忽略的是：服务端合并逻辑必须和客户端分片逻辑严格一致（比如都用 Math.Ceiling((double)fileLength / chunkSize) 算总块数），否则最后一块索引错位，整个文件就废了。
