C#怎么处理大文件分片上传_C#断点续传与合并文件块【高级】

C#大文件分片上传：从原理到实战的完整避坑指南

处理大文件上传，核心逻辑其实就一句话：客户端负责把文件切成块、并发上传并管理状态，服务端负责接收、校验、存储这些块，并在所有块到齐后按顺序合并。但魔鬼藏在细节里，一个环节设计不当，轻则上传失败，重则文件损坏还毫无头绪。

大文件分片上传必须自己管理块序号和校验

用 HttpClient 发起一堆并发 POST 请求，技术上并不复杂。真正的难点在于，服务端怎么知道收到的这一堆数据块，谁是谁？有没有丢？顺序对不对？

因此，C# 客户端必须在每次请求中，显式地告诉服务端四个关键信息：文件的唯一标识（比如一个 guid）、当前是第几块（chunkIndex）、总共有多少块（totalChunks），以及这块数据的“指纹”（chunkHash）。少了任何一项，后端都无法安全、准确地完成文件重组。

这里有两个常见的“坑”：一是只传了 chunkIndex 却忘了传 guid，结果不同用户上传的同名文件，块数据在服务器端混在一起，乱成一锅粥。二是为了图省事跳过了哈希校验，结果某块数据在网络传输中静默损坏，合并出来的文件无法打开，却找不到原因。

• 唯一标识是关键：别依赖原始文件名。可以用 Path.GetTempFileName() 为每个上传任务生成一个临时的 guid，全程复用这个ID。
• 块大小有讲究：建议固定为 4 * 1024 * 1024（即4MB）。太小了，HTTP请求头开销占比过高；太大了，单次传输内存压力大，一旦失败重传的成本也高。
• 校验算法要选对：计算块哈希，请使用 SHA256.HashData(chunkBytes)。别再考虑 MD5 了，在 .NET 6+ 中它已被标记为不安全算法。

断点续传靠服务端返回已上传块列表，不是客户端“记住”

很多人以为断点续传就是客户端自己记一下传到了第几块。这种思路非常脆弱——程序崩溃、磁盘写满、用户清理了临时文件，状态记录就全丢了。

真正健壮的断点续传，其核心是让服务端告诉你它已经收到了哪些块。具体做法是，在上传开始前，客户端先发起一个 GET /api/upload/chunks?fileId=xxx 请求。服务端查询数据库后，返回一个已成功接收的 chunkIndex 列表。

如果服务端没有提供这个查询接口，那么所谓的“断点续传”功能，很大程度上只是一种心理安慰。

• 设计要幂等且高效：这个查询接口必须设计得轻量，并充分利用HTTP缓存。客户端请求时可以带上 If-None-Match 头。
• 善用缓存机制：服务端可以为响应设置 ETag（例如 ETag: "chunks-{fileId}-v1"）。如果块列表没变，直接返回 304 Not Modified，客户端复用本地缓存即可，避免重复拉取。
• 智能跳过已传块：客户端收到 200 响应后，解析如 [0,2,4,5] 这样的JSON数组。接下来就只上传缺失的索引（比如1, 3, 6…），实现精准续传。

合并文件块必须用 FileStream 流式写入，禁用 File.WriteAllBytes

合并环节最容易犯的错误，就是把所有块数据一次性读进内存，拼成一个巨大的 byte[]，再写入文件。想象一下，一个1GB的文件，内存占用也接近1GB，OutOfMemoryException 几乎不可避免。

正确的做法是采用流式处理：先打开目标文件的 FileStream，然后按照块索引的顺序，逐个打开对应的临时块文件，读取数据块，并追加写入到目标流中。

这里同样要注意：读取单个块文件时，也别用 File.ReadAllBytes，对于大块，这依然有内存压力。应该使用 FileStream 配合 BufferedStream 来控制内存占用。

• 合并前先校验：在将每个块写入最终文件前，务必再次校验其哈希值。任何一块不匹配，都应立即抛出异常并中止合并，防止产生无效的中间文件。
• 文件打开模式要明确：使用 FileMode.Create 打开目标文件，确保旧内容被清空；使用 FileAccess.Write 和 FileShare.None，防止其他进程并发写入造成冲突。
• 及时清理临时文件：每个块文件合并完成后，应立即调用 File.Delete(chunkPath) 将其删除。不要依赖一个全局的“清理任务”，因为进程意外退出时，这些临时文件会一直占据磁盘空间。

.NET 6+ 推荐用 IAsyncEnumerable 做流式分片读取

传统的 FileStream.Read 配合 while 循环来分片，边界条件处理起来很繁琐，比如最后一块不足4MB时容易出错。.NET 6 引入的异步可枚举流（IAsyncEnumerable）为此提供了更优雅、更安全的解决方案：

async IAsyncEnumerable 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] 并复制数据要更高效。最后，创建 FileStream 时务必传入 FileOptions.Asynchronous 为 true，否则 ReadAsync 可能只是同步调用的包装，无法真正实现异步优势。

此外，这个模式天然支持取消（通过 CancellationToken）、进度报告（在 yield 前更新进度）以及与 IProgress 集成。但要注意，不要在 yield return 之间执行耗时的操作，否则会阻塞整个枚举过程。

最后提一个最容易被忽略，却足以导致前功尽弃的细节：服务端计算总块数的逻辑，必须与客户端完全一致。例如，双方都应使用 Math.Ceiling((double)fileLength / chunkSize) 这样的公式。如果一方用了向上取整，另一方用了向下取整，就会导致最后一块的索引错位，合并出来的文件自然是错误的。