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小时全天候智能回复用户消息,自动维护媒体主页,全平台渠道集成管理,电商物流平台一键绑定,让您出海轻松无忧!
相关推荐
辞旧 lekkk2 小时前
【Qt】信号和槽2301_809204703 小时前
JavaScript中严格模式use-strict对引擎解析的辅助.txtzjy277773 小时前
mysql如何选择合适的索引类型_mysql索引设计实战Aaswk4 小时前
Java Lambda 表达式与流处理笨蛋不要掉眼泪4 小时前
Mysql架构揭秘:update语句的执行流程万邦科技Lafite4 小时前
京东item_get接口实战案例:实时商品价格监控全流程解析秋95 小时前
ruoyi项目更换为mysql9.7.0数据库Andya_net5 小时前
MySQL | MySQL 8.0 权限管理实践-精确赋予库、表只读等权限Cyber4K5 小时前
【Python专项】进阶语法-系统资源监控与数据采集(1)冷小鱼5 小时前
JVM 异常崩溃排查全指南:从 Core Dump 到根因定位