ASP.NET Core文件夹上传实战：精确还原目录结构与断点续传

说个我最近刚接手过的真实场景：航空航天相关单位的内部资产管理系统，要把设计人员电脑上整个项目文件夹上传到服务器做归档，里面是型号图纸源文件、仿真模型、测试报告、工艺文档这些，目录层级往往按“型号-版本-专业-文档类型”排了好几层，一个文件夹动辄几千个文件，整体几个GB甚至更大。用传统的单文件上传控件面对这种需求基本没法用，用户只能自己在本地一层层手工找目录、手选文件，传完以后目录结构还全乱了。这个需求最折磨人的点不是“传得上去”，而是“精确”：目录结构不能被压扁、隐藏文件不能被夹带、非法文件类型必须在入口拦住、同一批文件万一断网不能全盘重来。这篇文章就把我用 ASP.NET Core 落地文件夹上传功能时的完整思路、代码和踩坑记录整理出来，给正在做类似系统、尤其是对数据管理有合规要求的读者一个可以直接参考的版本。

1. 文件夹上传在航空航天场景下，到底要“精确”在哪里

1.1 这不是“上传”，是“目录归档还原”

很多人一看到文件夹上传，觉得无非就是给 <input> 加个 multiple，或者点选文件夹后把所有文件一起扔给后端。但在航空航天这种数据管控场景里，用户真正的需求不是“文件到达服务器”，而是“一批文件按照原有目录树完整还原到归档区”。

我接触的这个单位里，型号资料的引用规则很严格，图纸编号、版本号、目录名之间是直接挂钩的。比如一个完整的结构强度分析文件夹，内部往往是：

text复制CR929-结构强度
├── 01-总体方案
│   ├── 强度计算书_V1.0.doc
│   └── 载荷工况汇总.xlsx
├── 02-仿真模型
│   ├── 翼身对接区.stp
│   ├── 翼身对接区.sim
│   └── 材料参数库.xml
└── 03-试验数据
    ├── 静力试验记录.pdf
    └── 测量点清单.csv

如果把这个目录扁平化传上去，数据库里堆了5000个文件，后续无论按型号检索还是按专业筛选，全部失效。所以这个“上传功能”第一要求是目录结构保真，而不是简单地把内容搬到服务器。

另一个容易忽略的问题是空目录。网页端读取文件夹只能拿到文件，拿不到没有文件的空目录，这会导致重建出来的目录树跟源目录不一致。航空航天项目资料里，“先建目录、后续补文件”是常态，空目录也有业务含义。这一点要在设计阶段就明确处理方案，后面第3章我会详细说。

1.2 “精确控制”应该拆成四个维度来理解

我在梳理需求的时候发现，光说“精确控制”太虚了，业务方和开发对“精确”的理解经常不在一个频道上。实际操作时我把它拆成了四个可量化、可验收的维度。

• 结构精确：服务器重建后的相对路径，必须和用户本机的目录结构完全一致。
• 文件精确：只允许业务允许的文件类型进入归档区，临时文件、系统文件、超限文件要在入口被识别并拦截。
• 资源精确：几百个文件并发上传时，服务端如果放开了跑，磁盘I/O、内存、TCP连接都会出问题；必须控制并发、限制请求体、设计合理队列。
• 合规精确：谁在什么时间上传了哪个型号目录、哪些文件被过滤掉了，都要有审计记录。航空航天领域的数据管理通常有质量体系审计要求，这些记录经常比上传功能本身更重要。

这四个维度也决定了技术方案不是一个“上传控件”能解决的，而是一个包含前端选择、服务端校验、任务队列、审计日志的完整链路。

1.3 这类需求的影响范围比想象中要大

文件夹上传一旦做起来，它不是一个孤立功能，而是和存储规划、权限体系、审计追溯、异常恢复绑定在一起的。我常提醒团队：如果领导说“你做个文件夹上传”，你千万不要只交一个上传页面，否则验收的时候一定会被四个部门追问——存储目录怎么规划？文件类型谁定的？断网重传怎么办？审计记录放哪里？

所以在动手写代码前，建议先明确影响范围。下图是我在项目里实际划分的功能边界（用表格表达，方便以后做验收项）：

2. 三种实现路径的选型对比

2.1 方案一：整个文件夹塞进一个请求，省事但风险高

第一种想法通常是把 input 换成：

html复制<input type="file" webkitdirectory multiple />

然后前端遍历拿到所有文件后，追加到同一个 FormData 里发给后端。这种方式在文件夹小于几十兆、文件数量只有几十个时能跑通，代码也短。但放到飞行器资料归档这种批量场景下，问题会迅速放大：

• 内存翻倍：浏览器收集到几万个文件后，一次性构建巨型 FormData，前端内存先吃紧。
• 单请求体积过大：Kestrel、IIS、反向代理都有请求体限制，文件多了很容易打到配置上限。
• 无法做文件级重试：只要其中一个文件失败，整批请求就失败，几GB内容全部重来。
• 服务端收到的实体可能被缓冲到内存或临时目录，形成巨大的磁盘与内存压力。

一句话，单请求全量提交只适合“上会材料”这种小包，不适合“型号资料归档”这种大批量场景。

2.2 方案二：前端/后端压缩成 ZIP 再处理，看着快但目录校验能力弱

还有人提出先压缩再上传，前端用 JSZip 把整个文件夹压成一个包，后端解压还原目录。这样做的确减少了请求次数，看起来“更快”，但仔细深挖会发现它在“精确控制”上有几个硬伤：

• 压缩耗时和内存都很高：几万个文件、几GB数据，在浏览器里执行压缩本身就是一场灾难；即使用后端压缩，也需要先把文件传到服务器，并没有省掉上传成本。
• 文件级过滤追责困难：用户上传的压缩包里可能混入了 .exe、病毒测试样本、隐藏的系统文件，后端解压时才过滤，审计记录只能记录到“压缩包”层级，很难精确到内部某个文件。
• 解压过程增加了路径穿越和 zip bomb 攻击面：解压代码写得不好，压缩包里的 ../../ 路径可以覆盖服务器任意目录。

ZIP 方案适合“一次性批量归档历史数据线上化”，不适合作为常态化的文件夹上传入口，因为它没有文件级状态管理和精确审计能力。

2.3 方案三：前端遍历 + 文件级异步上传，精确控制的核心路径

最终我采用的是“前端遍历 + 文件级上传 + 服务端按相对路径重建目录”的方案，流程是这样的：

1. 用户选择顶层文件夹，浏览器通过 File API 读出每个文件及其 webkitRelativePath（即该文件在所选文件夹内的相对路径）。
2. 前端生成一份待传文件清单，展示给用户，用户可取消某些文件，也可调整是否保留顶层目录。
3. 前端以单文件为一个 HTTP 请求单元，按可控并发数逐批上传。
4. 后端在归档根目录下按相对路径逐级创建目录，并对每个文件做扩展名校验、临时文件过滤、大小限制、路径穿越防护。
5. 前端维护每个文件的上传状态（待传、传输中、成功、失败），失败文件可以单独重试。
6. 批次结束时生成审计汇总，包括总数、成功数、失败数、被过滤列表。

这样做的好处是每一个文件都是一次独立的、可审计的操作单元，坏一个文件不会拖累整批，甚至网络断了之后重新打开页面还能续传那一批没传完的文件。缺点是需要多写不少代码。对于航空航天场景的可靠性要求，这个代价是值得的。

对应的框架选型上，新项目我强烈建议直接用 ASP.NET Core。旧 .NET Framework 的 Web Forms / MVC 5 不是做不到，而是异步接口、IFormFile 流式接收、跨平台部署这些能力都比 ASP.NET Core 差不少，后面踩坑部分我会专门说一个老框架下的经典报错。

3. 核心实现：用 ASP.NET Core 搭建可精确控制的文件夹上传链路

3.1 前端：如何拿到完整目录结构和待传清单

先看最基础的一步：怎么让浏览器允许用户选择一个文件夹，而不是只能选单个文件。关键属性是 <input> 上的 webkitdirectory。

html复制<input type="file" 
       id="folderPicker" 
       webkitdirectory 
       multiple />
<div>
  当前选择：<span id="fileCount">0</span> 个文件
  <label><input type="checkbox" id="stripRoot" checked /> 不保留顶层文件夹名</label>
  <button id="btnStartUpload" disabled>开始上传</button>
</div>

选择文件夹后，在 change 事件中读取文件列表，这里有个容易被忽略的点：每一个 File 对象上都有一个非标准属性 webkitRelativePath，它记录了文件相对于所选文件夹的路径。这个属性是后续重建目录的关键数据。

javascript复制const folderPicker = document.getElementById('folderPicker');
const stripRootCheck = document.getElementById('stripRoot');
const btnStartUpload = document.getElementById('btnStartUpload');
let fileQueue = [];

folderPicker.addEventListener('change', (e) => {
  const files = Array.from(folderPicker.files);
  fileQueue = files.map((file, index) => {
    let relativePath = file.webkitRelativePath || file.name;
    return {
      id: `file_${Date.now()}_${index}`,
      name: file.name,
      file: file,
      originalRelativePath: relativePath,
      relativePath: relativePath,
      size: file.size,
      status: 'pending', // pending | uploading | success | failed
      serverSaved: false
    };
  });

  document.getElementById('fileCount').textContent = fileQueue.length;
  btnStartUpload.disabled = fileQueue.length === 0;
});

// 用户确认是否需要剥掉顶层目录，例如用户选了“CR929-结构强度”这个文件夹
// 但系统内部归档根目录已经按型号建好了，所以可以省去这一层
stripRootCheck.addEventListener('change', () => {
  fileQueue.forEach(item => {
    if (stripRootCheck.checked) {
      const idx = item.originalRelativePath.indexOf('/');
      if (idx > -1) {
        item.relativePath = item.originalRelativePath.substring(idx + 1);
      } else {
        item.relativePath = item.name;
      }
    } else {
      item.relativePath = item.originalRelativePath;
    }
  });
});

这里有一个设计决策要解释一下：为什么要把“是否保留顶层文件夹名”做成可选项？因为实际业务中有两种需求都有。一种是用户直接把整个“型号文件夹”拖进来，服务器还原时希望从型号根开始；另一种是用户只选了型号文件夹里的“分系统资料”子目录，归档时业务方只想要从这个子目录开始的相对路径，不想把服务器上某个奇怪的本地目录名带进来。做了一个小开关，两种场景都不用给用户写额外的说明。

另外，webkitDirectory 在 Chrome、Edge、Firefox 以及较新的 Safari 中都支持，但在 IE11 中会退化为普通文件选择。遇上必须兼容 IE 的旧系统，前端可以做一个降级提示，限制用户每次选择一个文件或者手动拖拽多个文件。

3.2 上传队列：按文件逐个上传并控制并发数

拿到 fileQueue 之后，不能一次性全部并发发起请求，否则几千个文件同时 POST，浏览器连接数会先爆掉，服务端也会被并发写盘直接卡死。我通常把并发控制在上传客户端完成，保持一个相对稳定但又不会过度消耗服务端资源的窗口。

javascript复制async function processFile(item, retryCount = 3) {
  return new Promise((resolve) => {
    const xhr = new XMLHttpRequest();
    const formData = new FormData();
    // 注意：relativePath 直接放进 FormData，不要自己拼 URL 查询串
    formData.append('relativePath', item.relativePath);
    formData.append('file', item.file);

    xhr.open('POST', '/api/folderupload/upload');
    xhr.upload.onprogress = (evt) => {
      if (evt.lengthComputable) {
        // 可以把单文件进度回调给界面上传进度条
      }
    };

    xhr.onload = () => {
      if (xhr.status >= 200 && xhr.status < 300) {
        item.status = 'success';
        item.serverSaved = true;
        resolve(true);
      } else {
        item.status = 'failed';
        resolve(false);
      }
    };

    xhr.onerror = () => {
      item.status = 'failed';
      resolve(false);
    };

    xhr.send(formData);
  });
}

async function runUploadQueue() {
  const concurrency = 6;
  const pending = fileQueue.filter(f => f.status !== 'success');
  let currentIndex = 0;

  async function worker() {
    while (currentIndex < pending.length) {
      const item = pending[currentIndex];
      currentIndex++;
      item.status = 'uploading';
      await processFile(item);
    }
  }

  const workers = [];
  for (let i = 0; i < Math.min(concurrency, pending.length); i++) {
    workers.push(worker());
  }
  await Promise.all(workers);

  const failedItems = fileQueue.filter(f => f.status === 'failed');
  // 把失败文件统计到页面，供用户重试
  console.log('failed count:', failedItems.length);
}

这个方案里每个文件独立一个 POST 请求，在普通局域网络和云服务器之间的往返成本是可接受的。但要记住，浏览器对同一个域名的并发连接数是有限制的，HTTP/1.1 下一般 6 个左右，所以我在上面把并发数写死成 6。如果服务器在内网，并发可以调到 8~10，但我不建议无脑调高，后面第4章会解释服务端为什么也要按磁盘能力限流。

3.3 服务端：接收上传文件并安全重建目录

后端接口的核心是：接收一个普通文件 + 一个相对的路径字符串，在归档根目录下把路径解析好、校验好、然后落盘。

csharp复制[ApiController]
[Route("api/folderupload")]
public class FolderUploadController : ControllerBase
{
    private readonly IWebHostEnvironment _env;
    private readonly ILogger<FolderUploadController> _logger;
    private readonly IOptions<ArchiveOptions> _archiveOptions;

    public FolderUploadController(
        IWebHostEnvironment env,
        ILogger<FolderUploadController> logger,
        IOptions<ArchiveOptions> archiveOptions)
    {
        _env = env;
        _logger = logger;
        _archiveOptions = archiveOptions;
    }

    [HttpPost("upload")]
    [RequestSizeLimit(500 * 1024 * 1024)]
    public async Task<IActionResult> Upload([FromForm] FolderFileInput input)
    {
        var archiveRoot = Path.GetFullPath(_archiveOptions.Value.RootPath);
        var ret = await SaveFileInternal(archiveRoot, input);
        return Ok(ret);
    }

    private async Task<object> SaveFileInternal(string root, FolderFileInput input)
    {
        if (input?.File == null || string.IsNullOrWhiteSpace(input.RelativePath))
            return new { saved = false, reason = "参数不完整" };

        // 1) 规范化相对路径，并做路径穿越防护
        var relativeTmp = input.RelativePath.Replace('\\', Path.DirectorySeparatorChar)
                                            .Replace('/', Path.DirectorySeparatorChar);
        if (Path.IsPathRooted(relativeTmp))
        {
            _logger.LogWarning("拒绝绝对路径: {Path}", input.RelativePath);
            return new { saved = false, reason = "非法路径" };
        }

        var fullDir = Path.GetDirectoryName(Path.Combine(root, relativeTmp));
        var fullPath = Path.GetFullPath(Path.Combine(root, relativeTmp));

        if (!fullPath.StartsWith(root + Path.DirectorySeparatorChar, StringComparison.OrdinalIgnoreCase))
        {
            _logger.LogWarning("检测到路径穿越: {Path}", input.RelativePath);
            return new { saved = false, reason = "非法路径" };
        }

        // 2) 文件级过滤：临时文件、系统文件直接跳过，但记录结果
        var fileName = Path.GetFileName(input.RelativePath);
        if (fileName.StartsWith("~$") ||
            fileName.Equals("Thumbs.db", StringComparison.OrdinalIgnoreCase) ||
            fileName.Equals(".DS_Store", StringComparison.OrdinalIgnoreCase))
        {
            return new { saved = false, skipped = true, reason = "系统或临时文件" };
        }

        // 3) 扩展名白名单
        var ext = Path.GetExtension(fileName);
        var allowedExtensions = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
        {
            ".pdf", ".doc", ".docx", ".xls", ".xlsx", ".ppt", ".pptx",
            ".dwg", ".dxf", ".stp", ".step", ".igs", ".iges",
            ".x_t", ".x_b", ".sldprt", ".sldasm", ".3dxml", ".cgr",
            ".zip", ".7z", ".rar", ".txt", ".csv", ".xml"
        };
        if (!allowedExtensions.Contains(ext))
        {
            _logger.LogWarning("拒绝了不允许的扩展名文件: {FileName}, 扩展名: {Ext}", fileName, ext);
            return new { saved = false, skipped = true, reason = $"不允许的扩展名 {ext}" };
        }

        // 4) 限制单文件大小
        if (input.File.Length > 500 * 1024 * 1024)
            return new { saved = false, reason = "单文件超过500MB" };

        // 5) 写入归档目录
        Directory.CreateDirectory(fullDir ?? Path.GetDirectoryName(root)!);
        await using (var fs = new FileStream(fullPath, FileMode.Create, FileAccess.Write,
                       FileShare.None, 81920, FileOptions.Asynchronous))
        {
            await input.File.CopyToAsync(fs);
        }

        // 6) 生成审计信息，可以按需插入数据库或日志表
        return new { saved = true, fileName = fileName, fullPath = fullPath };
    }
}

public class FolderFileInput
{
    public IFormFile File { get; set; } = null!;
    public string RelativePath { get; set; } = null!;
}

写路径穿越校验时我特意用了 Path.GetFullPath 再做前缀判断，而不是简单地用字符串包含判断，原因是：Path.Combine 遇到绝对路径时会直接忽略第一个根目录参数。比如输入路径是 C:\foo.exe，组合后变成 C:\foo.exe，如果不用 Path.IsPathRooted 先拦截，后面做前缀判断虽然也会拦截，但提前判断会更清晰。

还有一个坑是“文件名里带中文”的问题。某些旧 IIS 站点如果配置用了服务器默认编码，中文文件名传上来可能变成乱码，在 ASP.NET Core 中默认使用 UTF-8 处理表单，基本没问题，但如果是老 .NET Framework，建议检查 web.config 中的 requestEncoding 和 responseEncoding 是否都是 UTF-8，否则相对路径一旦包含中文，服务器建的目录名称全乱。

3.4 业务层要过滤的不只是“扩展名”，还要过滤隐藏文件

航空航天单位里设计人员的电脑环境并不“干净”，文件夹里常混着各种系统生成文件。比如 Windows 下打开 Excel 生成的临时锁文件 ~$强度报告.xlsx，Windows 缩略图缓存 Thumbs.db，Mac 电脑上产生的 .DS_Store。这些文件如果原样进归档，既没有业务价值，还会污染后续检索结果。

这部分过滤规则最好做成配置表而非硬编码。因为不同的业务组允许的文件类型可能不同，设计部门可能允许上传 CAD 图纸，而资料室可能只允许上传 PDF 终版文件。把扩展名白名单放数据库或者配置中心，系统管理员随时可以调整，不需要开发人员改代码发版。

我在项目里还把“过滤行为”也做成了审计事件：过滤掉的文件不能只静默丢弃，前端要能看到“有3个文件因扩展名不允许被跳过”，服务端也要记录是哪一批、哪个用户、哪台电脑产生的。在合规审计时，这一条能回答“这个文件夹上传时到底有哪些文件被拒了，理由是什么”。

4. 大批量场景下的可靠性与并发控制

4.1 服务端不能“来一个写一个”直接硬扛

客户端并发已经限到 6 了，但服务端可能同时有多个人在传不同的型号目录。如果不做服务端限流，几个用户一并发力，磁盘容易被拖垮，而且是所有应用一起卡。写入操作是磁盘密集型，不是 CPU 密集型，并发数太高时反而因为磁头寻道或者 SSD 队列堆积变慢。

我这里加了一个进程级信号量，限制同时写文件的数量：

csharp复制public class UploadSaveGate
{
    private static readonly SemaphoreSlim _gate = new SemaphoreSlim(4);
    public static SemaphoreSlim Instance => _gate;
}

// 写在之前的 SaveFileInternal 方法中：
await UploadSaveGate.Instance.WaitAsync();
try
{
    Directory.CreateDirectory(fullDir!);
    await using (var fs = new FileStream(fullPath, FileMode.Create, FileAccess.Write,
                   FileShare.None, 81920, FileOptions.Asynchronous))
    {
        await input.File.CopyToAsync(fs);
    }
}
finally
{
    UploadSaveGate.Instance.Release();
}

把并发写盘数控制在 4，不是凭空拍的。当时我们在测试环境做了压测，同一批 2000 个小文件，分别用 1、4、8、16 的并发写盘，结果是并发为 4 时吞吐最高；并发到 16 后，磁盘 I/O 等待时间明显上涨，整体完成时间反而变长。如果是全固态硬盘的环境可以适当调高，但保守方案在任何存储上都稳。

4.2 断点续传和失败重试，没必要靠浏览器插件

很多人一听到断点续传就先想到分块上传、要给文件排序、维护 chunk 索引。但文件夹上传的断点续传，绝大多数痛点不在“一个大文件传一半断了”，而在于“几千个小文件传了 80%，有一个批次失败了，怎么只补剩下的 20%”。

因此这里的续传设计应以“文件粒度”为单位，而不是“字节块粒度”。方案是：前端维护每个文件的上传状态，在上传前先把整个文件清单登记到服务端生成本批次号，上传过程中每成功一个文件，后端就往任务表写一条记录。下次页面重新打开时，前端调一个接口查询该批次已经成功的文件列表，把成功项从待传队列里剔除。

json复制POST /api/folderupload/query
{
  "batchId": "20240112-CR929-001"
}

返回：

json复制{
  "batchId": "20240112-CR929-001",
  "successFiles": [
    "01-总体方案/强度计算书_V1.0.doc",
    "01-总体方案/载荷工况汇总.xlsx"
  ],
  "totalCount": 2024
}

前端拿这个成功清单过滤本地队列，没传过的一律重新上传。这样做续传不需要后端实现复杂的分块协议，代码量少，效果也直观。数据库落库的时机就在刚才服务端代码的第6步附近，如果项目里已经有业务数据库，可以建一张上传明细表来存这些记录。

4.3 批次进度反馈要真实，别只做单文件进度条

用户看到几千个文件要传，最怕的是页面卡住、没有总进度。单文件进度条只能说明当前这个文件在传，用户根本不知道整体还剩多少。我的做法是在前端维护三个指标：已成功文件数、总体文件数、已成功字节数、总体字节数。每完成一个文件，更新这三个数字。

更彻底一点的做法是用 SignalR 做实时推送，但考虑到很多内部系统前端还是传统的页面刷新模式，引入 SignalR 会加重项目复杂度。我从最简单的方案做起：前端每完成一个文件，把队列状态写进本地 sessionStorage；如果页面刷新，恢复本地队列并重新查询服务端成功清单。整体进度就是“成功数 / 总数”，而不是依赖服务端实时推送。

4.4 大文件与海量小文件要差异化处理

文件夹上传场景里有两类极端情况要区分：一是单个文件特别大，比如 2GB 的仿真结果压缩包；二是单个文件很小但数量特别多，比如几千个 10KB 的文本文件。这两类混在一起时，资源消耗模型差异很大。

单独一个 2GB 大文件如果走普通文件上传接口，IIS 默认限制只有 30MB，需要额外调整请求体限制和请求超时。这种情况下我建议单独走一套大文件分块上传通道，把文件切成若干 20MB~50MB 的片段，片段按顺序上传、服务端合并。而海量小文件则更适合走本文章说的文件级并发通道。

所以在整体架构上，我会在“文件夹上传”总入口内部做文件级分流：

• 单文件小于等于 200MB：走普通异步上传接口。
• 单文件大于 200MB：提示用户改用大文件分块通道，或者由后端自动切换到专用上传接口。
• 单文件夹文件数超过 5000 个：前端弹出强提示，要求用户分批归档，避免单次批次过大导致中途出问题时排查困难。

5. 常见线上问题与排查实录

5.1 热搜里那个“检测到潜在危险的 Request.QueryString 值”到底怎么治

这个经典报错在热搜词里出现了，我想说明一点：它背后不是“上传文件太大”或“权限不够”，而是 .NET Framework 时代 ValidateRequest 机制把带有 &、<、> 等字符的 QueryString 当成“潜在危险”拦截了。

典型的触发场景是什么？假设用户文件夹里有个文件名是 A&B结构件图纸.pdf，前端代码如果图省事，把它拼到 URL 上：

javascript复制xhr.open('POST', '/api/upload?path=' + relativePath);

服务端解析 relativePath 时看到 &，认为这是参数分隔符，造成参数被截断、出现额外键值，同时 ASP.NET 的请求验证机制直接把请求拦成 500。很多人见到这个报错后第一反应是去 web.config 里设置：

xml复制<system.web>
  <httpRuntime requestValidationMode="2.0" />
  <pages validateRequest="false" />
</system.web>

这样确实能压掉报错，但这种做法等于关闭了一整层的输入校验，而且治标不治本，文件名进 QueryString 本身就容易遇到 URL 编码、长度限制、参数污染等问题。正确解法是把路径放在 Request Body 的 FormData 里，而不是放进 URL 查询串。本文章前端的例子中就是用 formData.append('relativePath', item.relativePath) 传输路径的，路径根本不会出现在 URL 上，自然也不会被 QueryString 校验机制拦截。

如果是旧 ASP.NET MVC 项目没条件大规模改造，仍然坚持用小表单接收文件，那么也要注意：文件名传过来时应当做服务端编码校验，不能在用户提交一次后就完全信任浏览器已经编码了。

5.2 IIS 发布 ASP.NET Core Web API 后，文件夹一直传不上去

用 ASP.NET Core Web API 发布到 IIS 后，文件夹上传最常见的现象是：小文件传没问题，一传 50MB 以上的文件就返回 404、413 或者直接超时。这通常有三个层级的限制没调到位。

第一层是 IIS 的请求过滤模块，默认 maxAllowedContentLength 约 30MB。修改方法是编辑站点根目录的 web.config：

xml复制<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="524288000" />
    </requestFiltering>
  </security>
  <aspNetCore processPath="dotnet"
              arguments=".\YourApp.dll"
              stdoutLogEnabled="false"
              stdoutLogFile=".\logs\stdout"
              hostingModel="inprocess" />
</system.webServer>

注意这里的单位是字节，524288000 是 500MB。很多人在应用层设置了 [RequestSizeLimit]，却忽略了这一层 IIS 的限制，导致怎么调都不生效。

第二层是 ASP.NET Core 中 [RequestSizeLimit] 或 MultipartBodyLengthLimit 的限制。我上面给控制器标注了 500MB，但如果用 Kestrel 部署在 Linux 环境，还可能有 Kestrel 的 MaxRequestBodySize 默认 30MB 的限制。需要显式放开：

csharp复制builder.WebHost.ConfigureKestrel(options =>
{
    options.Limits.MaxRequestBodySize = 524288000;
});

第三层是 IIS