C#文件上传断点续传服务端 C#如何设计支持断点续传的API

asp.net core分片上传需禁用请求体自动缓冲并手动处理range头，分片存临时文件后单线程seek写入合并，进度持久化至数据库并校验哈希防损坏。

ASP.NET Core 中如何接收分片上传的 Range 请求

断点续传本质是 http 分片上传 + 服务端状态维护，服务端必须能识别并处理带 Range 头的请求，否则浏览器发来的续传请求会被当成普通 POST 拒绝或重置。

关键不是“自己解析 Range”，而是让 ASP.NET Core 不自动读取整个请求体，否则会丢掉原始流、无法按字节偏移写入。需在 Startup.cs 或 Program.cs 中关闭自动缓冲：

• services.Configure<iisserveroptions>(options => options.AllowSynchronousIO = true);</iisserveroptions>（仅 IIS，慎用）
• 更稳妥的是：在控制器方法上加 [DisableRequestSizeLimit]，并在方法内用 HttpContext.Request.Body 直接读取原始流
• 务必检查 HttpContext.Request.Headers["Range"] 是否存在，格式如 bytes=1024- 或 bytes=1024-2047，缺失则视为新上传

C# 后端如何安全拼接分片文件（避免并发写冲突）

多个分片可能并发到达，直接 FileStream 追加写同一文件极易损坏数据——windows 下 FileMode.append 不保证原子性，linux 下 lseek + write 也非线程安全。

真正可行的做法是：每个分片先独立保存为临时文件（如 upload_{guid}_{chunkIndex}.tmp），全部接收完成后，用单线程顺序读取并合并到目标文件。合并时用 File.OpenWrite 配合 Seek 定位写入，确保偏移准确：

• 从 Range 头解析出起始位置，比如 bytes=524288- → offset = 524288
• 用 fs.Seek(offset, SeekOrigin.Begin) 再 fs.Write()，不要依赖文件当前长度
• 合并前校验所有分片的 Content-MD5 或客户端传来的 x-chunk-hash，防止网络错包

如何持久化上传进度（避免重启后丢失状态）

内存存 Dictionary<string uploadsession></string> 最简单，但进程一重启全丢。生产环境必须落盘或进数据库，且不能每来一个分片就写一次 DB —— 性能扛不住。

折中方案是：内存维护活跃会话（超时自动清理），仅在关键节点落库：

• 首次上传时插入一条记录，含 uploadId、totalSize、status = "uploading"
• 每个分片成功写入临时文件后，更新 lastChunkIndex 和 receivedBytes
• 合并完成瞬间，把 status 改成 "completed" 并删掉所有临时文件
• 用 uploadId 做唯一键，避免重复提交；用数据库行锁（如 sql Server 的 UPDLOCK）防并发更新冲突

前端传 uploadId 但服务端找不到记录怎么办

常见于用户关浏览器又重开、或上传中断超过服务端清理周期（比如设了 24 小时自动删过期会话）。此时不应直接报错 404，而要返回可恢复的元信息。

建议响应体包含：{"uploadId": "xxx", "receivedBytes": 123456, "totalSize": 10485760}，让前端决定继续传还是重试。注意两点：

• 不要暴露临时文件路径、服务器磁盘结构等敏感信息
• 若 receivedBytes 为 0，说明服务端已清理，前端应触发全新上传流程
• 所有接口必须校验 uploadId 格式（如正则 ^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$），防 SQL 注入或路径遍历

最麻烦的其实是分片校验和对不上、网络层悄悄截断、或者客户端没正确设置 Content-Range 导致服务端算错 offset——这些错误不会抛异常，只会让最终文件损坏，得靠合并后的哈希比对才能发现。