前端转型全栈（六）——深入浅出：文件上传的原理与进阶

文件上传是 Web 开发中最常见的功能之一。从前端选择一张图片，到后端将其保存在服务器上，这中间到底发生了什么？本文将从基础原理到进阶知识，带你全面了解文件上传的本质。

1. 为什么不能用 JSON 传文件？

平时我们发送普通的 HTTP 请求，最常用的格式是 application/json。JSON 本质上是一串文本字符串。

如果我们要用 JSON 传一张图片，必须先把图片的二进制数据转换成文本（最常见的是 Base64 编码）。

例如：{"filename": "avatar.png", "data": "data:image/png;base64,iVBORw0KGgo..."}

这种做法有三个致命缺点：

体积膨胀 ：Base64 编码会将原本的二进制数据体积增大 33% 左右，浪费带宽。
内存消耗极大：无论是前端将大文件转成 Base64 字符串，还是后端解析这个巨大的 JSON 字符串，都需要将整个文件加载到内存中。如果传一个 1GB 的视频，服务器内存可能直接撑爆（OOM）。
解析效率低：JSON 解析器处理超大字符串非常耗时。

因此，HTTP 协议专门设计了一种适合传输二进制大文件的格式：multipart/form-data。

2. 核心原理：`multipart/form-data` 是什么？

multipart/form-data 的核心思想是：分块传输，边界隔离。

2.1 前端的准备工作

在前端，我们通常使用 FormData 对象来包装文件：

javascript 复制代码

const formData = new FormData();
formData.append('username', 'kyj'); // 普通文本字段
formData.append('file', file);      // 二进制文件字段

// 发送请求
fetch('/upload', { method: 'POST', body: formData });

当你把 FormData 交给浏览器发送时，浏览器会自动做两件事：

设置请求头 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXyz123。
这里的 boundary (边界线) 是浏览器随机生成的一串字符，它的作用就像是"快递箱里的隔板"，用来把不同的字段和文件隔开。

2.2 网络中的 HTTP 报文长什么样？

在网络传输中，这段请求会被包装成如下格式：

http 复制代码

POST /upload HTTP/1.1
Host: localhost:3000
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXyz123

------WebKitFormBoundaryXyz123
Content-Disposition: form-data; name="username"

kyj
------WebKitFormBoundaryXyz123
Content-Disposition: form-data; name="file"; filename="avatar.png"
Content-Type: image/png

(这里是图片的一大堆乱码一样的纯二进制数据...)
------WebKitFormBoundaryXyz123--

解析报文：

每一块数据都以 --boundary 开始。
紧接着是描述这块数据的头部信息（如字段名 name、文件名 filename、文件类型 Content-Type）。
然后是一个空行。
接着是真正的数据内容（文本或二进制）。
最后以 --boundary-- 结束整个报文。

3. 后端如何接收与存储？（以 Node.js/NestJS 为例）

当这段报文到达后端时，Node.js 原生接收到的是一段段的数据流 (Stream) 。如果让我们自己写代码去根据 boundary 拆解这些流，会非常痛苦且容易出错。

因此，我们通常会引入专门的中间件，比如 multer （在 NestJS 中被封装为 FileInterceptor）。

3.1 Multer 的工作流程

监听数据流：Multer 监听 HTTP 请求的输入流。
寻找边界 ：它根据请求头中的 boundary 字符串，在数据流中寻找"隔板"。
分离数据 ：遇到普通文本字段，就存入内存（挂载到 req.body）；遇到文件字段，就提取出二进制流。
流式写入磁盘 ：这是最关键的一步。Multer 不会把整个文件加载到内存里，而是边接收边写入 。它在服务器硬盘上（如 ./uploads 目录）创建一个空文件，然后把提取出的二进制数据一点点"流"进去。
生成元数据 ：写入完成后，它把这个文件的信息（如新文件名、大小、路径等）整理成一个对象，挂载到 req.file（或 NestJS 的 @UploadedFile()）上，交给你写的业务代码。

通俗的比喻：

前端：像是一个发件人，把"照片（文件）"放进"快递箱（FormData）"，并用"胶带（boundary）"封好。
网络：快递小哥把箱子运到服务器。
后端 (Multer)：像是一个收发室大爷，他负责拆开快递箱（解析 multipart），把照片拿出来放进"档案柜（uploads 文件夹）"，然后给你一张"取件小票（返回的文件名/URL）"。前端下次拿这张小票，就能预览这张照片了。

4. 进阶广度：文件上传的常见痛点与高级方案

在实际的企业级项目中，简单的单文件上传往往不够用，还会面临以下挑战：

4.1 大文件上传与断点续传

如果用户上传一个 5GB 的视频，中间网络断了怎么办？重头再传体验极差。
解决方案：分片上传 (Chunked Upload)

前端切片 ：利用 HTML5 的 File.slice() 方法，将 5GB 的文件切成 1000 个 5MB 的小块（Chunk）。
并发上传 ：前端并发发送这些小块，每个请求带上当前块的索引（如 chunkIndex: 5）和文件的唯一标识（如文件的 MD5 值）。
后端合并：后端接收这些小块并暂存。当前端通知"所有块已传完"时，后端按索引顺序将这些小块合并成一个完整的文件。
断点续传：如果中断，前端只需向后端查询"你已经收到了哪些块？"，然后只上传缺失的块即可。

4.2 秒传技术

你有没有发现，在网盘里上传一部热门电影，瞬间就传完了？
原理：文件指纹 (Hash)

前端在上传前，先计算整个文件的 MD5 值（文件的唯一指纹）。
将 MD5 发给后端查询："服务器上有这个文件吗？"
如果后端数据库里已经有这个 MD5 对应的文件记录，直接告诉前端"上传成功"，并在数据库里给当前用户增加一条关联记录即可。实际上根本没有发生文件传输。

4.3 存储架构演进

单机存储（如本项目） ：存在本地 ./uploads 目录。缺点是无法横向扩展，服务器挂了文件就丢了。
分布式文件系统：如 FastDFS、MinIO。适合自建机房的企业，支持高可用和扩容。
云存储 (OSS/S3) ：目前最主流的方案（如阿里云 OSS、腾讯云 COS、AWS S3）。
- 传统模式：前端传给后端 -> 后端再传给 OSS。缺点是占用后端带宽，速度慢。
- 直传模式 (最佳实践)：前端先向后端请求一个"临时签名凭证 (STS)"，然后前端直接带着凭证将文件上传到 OSS。后端完全不参与文件流的传输，极大减轻了服务器压力。

5. 总结

文件上传看似简单，只是调个接口，但其背后涉及了 HTTP 协议的底层设计、流式处理的思想，以及在面对大文件、高并发时的架构演进。掌握这些原理，不仅能帮你快速定位日常开发中的 Bug，也能在面对复杂业务需求时设计出更优雅的方案。