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——这些错误不会抛异常，只会让最终文件损坏，得靠合并后的哈希比对才能发现。
