ASP.NET Core 上传大文件需同时配置 IIS 最大请求体和控制器级 RequestSizeLimit；断点续传依赖服务端维护已上传字节数并校验唯一 ID；下载须流式处理避免内存溢出；合并分块需按序拼接并保证原子性。WebAPI 上传大文件时 IFormFile 直接报错或截断ASP.NET Core 默认限制单个请求体大小为 30MB，超过就直接 400 或连接重置，根本进不到控制器逻辑。不是代码写错了，是管道在模型绑定前就拦下了。必须同时改两处配置：Startup.cs（.NET 5+ 在 Program.cs）里加 ConfigureServices 配置：services.Configure<IISOptions>(options => options.MaxRequestBodySize = null);（仅 IIS）全局或控制器级加 RequestSizeLimit(200_000_000) 或更宽松的值（单位字节），且需确保中间件顺序在 UseRouting 之后、UseEndpoints 之前前端 fetch 或 axios 发送时别用 FormData 拼错字段名------后端 FromForm IFormFile file 绑定的字段名必须和表单中 append("file", blob) 的第一个参数完全一致断点续传核心：怎么判断文件块是否已存在并跳过关键不在"传"，而在"查"。每次上传前客户端必须先发一个 HEAD 或 GET 请求，带 Range 和文件唯一标识（如 Content-MD5 或自定义 X-Upload-ID），服务端根据这个 ID 查本地临时目录或数据库，返回已接收的字节数（206 Partial Content + Content-Range）或 200 OK 表示全新上传。不要依赖客户端传来的"当前 offset"，它可能伪造或错位；服务端必须自己维护每个 X-Upload-ID 对应的已写入长度：用 ConcurrentDictionary<string, long> 存 ID → 已写大小（开发期够用，生产建议换 Redis）写文件时用 FileStream 构造函数指定 FileMode.Append，但注意：必须先 Seek 到指定位置再写，否则会追加在末尾，破坏分块顺序客户端收到 206 后，从 Content-Range 解析出 bytes 0-1048575/2097152 中的 1048576，作为下一块的起始偏移HttpClient 下载大文件卡死或内存爆掉别用 response.Content.ReadAsStringAsync() 或 ReadAsByteArrayAsync()------这是把整个文件读进内存，1GB 文件直接 OOM。下载必须流式处理。正确做法是拿到 HttpContent.ReadAsStreamAsync() 后，用 Stream.CopyToAsync() 直接写入本地文件流： JoinMC智能客服 JoinMC智能客服，帮您熬夜加班，7X24小时全天候智能回复用户消息，自动维护媒体主页，全平台渠道集成管理，电商物流平台一键绑定，让您出海轻松无忧！