文件上传
文件上传策略：一次请求仅上传一个文件#
勿将文件与其他数据一起上传#
- 上传文件时请求数据的格式必须为
multipart/form-data，从而使得其他字段将不能以其他格式（如application/json）提交 - 如果其他字段存在错误，那么则必须重新上传文件
避免多文件上传#
- 多文件同时上传会导致请求数据的体积过于庞大，造成网络阻塞
- 不利于请求数据限制策略的实现
请求数据大小要如何限制？
若一个文件存在错误，其他文件要如何处理？ - 在不与服务器建立专门的通信的情况下无法确定每个文件的上传状况
避免使用 Base64 作为文件数据上传#
- Base64 编码使用四个字节表示三个字节，因此上传的数据的体积通常会比正常大 33%
如果数据压缩率（注意：不是图像压缩质量）达不到 75%，那么使用 Base64 将失去意义
- 解码 Base64 字符串会占用大量服务器内存
使用字节流的形式上传文件时，服务器端只是在磁盘上建立一个写入流并将请求的数据流与之对接，通常数据缓冲大小为 32KB；
但使用 Base64 时服务器必须将所有数据加载到内存后再进行解码。 - 解码 Base64 字符串会消耗较多服务器 CPU 资源
- 图像文件的 Base64 中没有包含 EXIF 的方向信息，如果直接将其作为文件数据提交给服务器，最后图像的显示方向可能会与预期不符，要解决该问题则必须使用其他库读取原图像文件的方向信息，并将该信息以额外的字段提交给服务器
一次请求仅上传一个文件#
- 文件上传请求仅上传一个文件，且不提交其他业务数据
- 浏览器端无需做额外实现（通常，浏览器仅支持一个页面发送 5 个并发请求）
- 一个文件存在错误不会影响其他文件，重新上传发生错误的文件即可
- 每个文件的上传状况可单独呈现
上传文件的保存#
- 文件上传请求成功时将文件保存到临时资源路径下
- 在相应的业务处理成功后再将文件移动到相应的位置
- 定期清理临时上传文件，从而避免由于后续业务处理失败或放弃处理导致的垃圾文件过多
例如，文件保存于磁盘时，可每天执行一次清理脚本，删除创建于一天前的文件；
或者，文件保存于 MongoDB 的 GridFS 时，可将文件的过期时间设置为一天后。