Pinxian Li说个我最近刚接手过的真实场景：航空航天相关单位的内部资产管理系统，要把设计人员电脑上整个项目文件夹上传到服务器做归档，里面是型号图纸源文件、仿真模型、测试报告、工艺文档这些，目录层级往往按“型号-版本-专业-文档类型”排了好几层，一个文件夹动辄几千个文件，整体几个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 这类需求的影响范围比想象中要大
文件夹上传一旦做起来，它不是一个孤立功能，而是和存储规划、权限体系、审计追溯、异常恢复绑定在一起的。我常提醒团队：如果领导说“你做个文件夹上传”，你千万不要只交一个上传页面，否则验收的时候一定会被四个部门追问——存储目录怎么规划？文件类型谁定的？断网重传怎么办？审计记录放哪里？
所以在动手写代码前，建议先明确影响范围。下图是我在项目里实际划分的功能边界（用表格表达，方便以后做验收项）：
| 影响域 | 要回答的问题 | 交付物 |
|---|---|---|
| 前端交互 | 用户怎么选目录、看进度、处理失败文件 | 目录选择界面、上传队列、进度反馈 |
| 服务端接收 | 怎么把每个文件按照相对路径落到指定存储根目录 | 异步上传接口、目录重建逻辑 |
| 安全过滤 | 哪些文件能进来、哪些必须拒绝 | 扩展名白名单、路径穿越校验、大小限制 |
| 任务可靠性 | 断了网、浏览器关了、服务器重启了怎么办 | 批次登记、幂等校验、续传清单 |
| 审计合规 | 谁传了什么、结果如何、谁审核了 | 上传日志表、批次清单、MD5摘要记录 |
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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 方案三：前端遍历 + 文件级异步上传，精确控制的核心路径
最终我采用的是“前端遍历 + 文件级上传 + 服务端按相对路径重建目录”的方案，流程是这样的：
- 用户选择顶层文件夹，浏览器通过 File API 读出每个文件及其
webkitRelativePath（即该文件在所选文件夹内的相对路径）。 - 前端生成一份待传文件清单，展示给用户，用户可取消某些文件，也可调整是否保留顶层目录。
- 前端以单文件为一个 HTTP 请求单元，按可控并发数逐批上传。
- 后端在归档根目录下按相对路径逐级创建目录，并对每个文件做扩展名校验、临时文件过滤、大小限制、路径穿越防护。
- 前端维护每个文件的上传状态（待传、传输中、成功、失败），失败文件可以单独重试。
- 批次结束时生成审计汇总，包括总数、成功数、失败数、被过滤列表。
这样做的好处是每一个文件都是一次独立的、可审计的操作单元，坏一个文件不会拖累整批，甚至网络断了之后重新打开页面还能续传那一批没传完的文件。缺点是需要多写不少